Re: egcs 10-31 and UnixWare

[Jeffrey A Law <law at cygnus dot com>]

  In message <19971109131009.64698@dgii.com>you write:
  > Given the similarity in the symptoms and the environments, I 
  > suspect that the Unixware and OpenServer problems are related.
Yup.  That's why I suggested the Unixware folks talk to you :-)

  > > Basically I don't see how the __do_global_dtors_aux routine from gcc's
  > > crtstuff.c can call abort -- unless abort is on the dtor list.  So I'm
  > > wondering if you're getting the correct crtbegin.o file.
  > 
  > Abort isn't on the dtor list in my case, but I"m starting to 
  > really distrust GDB here.   According to a print __DTOR_LIST__[1],
  > I don't have a dtor list, clearly there are destructors running.
I never trust backtraces or other frame stuff if the program was compiled
with optimization -- unless _I_ did the gdb port.

  > > Or maybe gdb is lying and you called abort from __deregister_frame which
  > > would indicate that the exception handlers never got registered in the
  > > first place or were clobbered.
  > 
  > What if exit() is recursing?  
Hmmm.  Interesting question.

  > Breakpoint 2, 0x800196c4 in exit ()
  > (gdb) cont
  > Continuing.
  > 
  > Breakpoint 3, 0x80485a6 in __do_global_dtors_aux ()
  > (gdb) cont
  > Continuing.
  > --count
  > --count
  > 
  > Breakpoint 2, 0x800196c4 in exit ()
  > (gdb) cont
  > Continuing.
Wild.  That shouldn't be happening....  I think we've got something
to work backwards from now.

  > > Can you compile frame.c with debug symbols, add it to libgcc, then put
  > > a breakpoint in __deregister_frame to see what's going on?
  > 
  > My breakpoint on __deregister_frame never gets called.
What about recompiling the crt* files with -g -O0 so you can get
control of do_global_dtors_aux and possibly see how in the hell
it's calling exit!

Hmmm, maybe EH_FRAME_SECTION_ASM_OP isn't defined, and do_global_dtors_aux
is actually finishing, which would drop us back into our friend fini_dummy.

jeff