Re: disturbing g++ 971031 results. defer-pop to blame?

[Jeffrey A Law <law@cygnus.com>]

  In message < 19971103011246.03918@dgii.com >you write:
  > GDB that I built from 4.14-95q4 (i486-unknown-sco3.2v5.0.0elf) handles 
  > the binaries in question just fine.   GDB 4.16 built from virgin FSF 
  > sources isn't useful on my ELF binaries.   I'll chase this later...
Sounds wise :-)

  > Program received signal SIGSEGV, Segmentation fault.
  > 0x8059187 in .fini ()
Now we're getting somewhere...

  > If I look at the tail end of the object, the reason for our
  > crash is more apparent:
  > 
  > 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.

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...

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.

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.

Jeff