From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Lipe To: law@cygnus.com Cc: egcs@cygnus.com Subject: Re: disturbing g++ 971031 results. defer-pop to blame? Date: Mon, 03 Nov 1997 09:43:00 -0000 Message-id: <19971103101346.15855@dgii.com> References: <19971103011246.03918@dgii.com> <16810.878541954@hurl.cygnus.com> X-SW-Source: 1997-11/msg00104.html > > 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