This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: disturbing g++ 971031 results. defer-pop to blame?
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x8059187 in .fini ()
> Now we're getting somewhere...
>
> > Disassembly of section .fini:
> >
> > 0805917c <_fini>:
> > 805917c: e8 c7 f9 fe ff call 8048b48 <__do_global_dtors_aux>
> > 8059181: 90 nop
> > 8059182: 90 nop
> > 8059183: 90 nop
> >
> > 08059184 <.fini>:
> > 8059184: 4c decl %esp
> > 8059185: cd 04 int $0x4
> > 8059187: 08 c2 orb %al,%dl
> >
> > 08059188 <.fini>:
> > 8059188: c2 00 00 ret $0x0
> > 805918b: 90 nop
> Hmmmm.
> If you look at fini_dummy in crtstuff.c you'll see how this happened:
>
> static void
> fini_dummy ()
> {
> asm (FINI_SECTION_ASM_OP);
> __do_global_dtors_aux ();
> #ifdef FORCE_FINI_SECTION_ALIGN
> FORCE_FINI_SECTION_ALIGN;
> #endif
> asm (TEXT_SECTION_ASM_OP);
> }
>
> We switch into the FINI section, emit the call, align the section,
> then switch out -- without ever emitting a return.
Right. This code never emits a return. The code in the OS-provided
crtn.o does. This is why it's linked last.
> So, when we return from do_global_dtors_aux, we just wander into a section,
> which I'm guessing is data, not code. Eventually something good or
> bad happens...
I don't think we wander anywhere. We return, execute a couple of nops
then slam into some completely bogus-looking opcodes. Of course, if
those bogus-looking opcodes were less bogus, we'd then execute that
perfectly lovely ret that crtn.o gave us.
> The other possibility is the code at 0x8059184 is getting stomped on
> sometime during the program execution (would assume that it's r/w which
> might be true for the special initializer/finalizer sections.
It's definitely in the executable that way. The results I
included are the output of an 'objdump --disassemble'. A 'dis'
(approximate SCO equivalent of the same, only lamer) confirms
this. So nobody got a chance to trounce those sections.
objdump shows that .fini is read-only:
8 .fini 00000010 0805917c 0805917c 0001117c 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
> I guess the first thing I'd do is determine what kind of stuff is
> at 0x8059184 (code vs data) and move forward from there.
It *should be* code, becuase this is what we're going to start
executing at tear-down time . It looks like it *is* data or
random trash).
If nobody recognizes those bytes as something useful that just
landed in the wrong section, I suppose I'll have to find where
they're coming from.
RJL