Re: egcs 10-31 and UnixWare

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

  In message <19971109145838.26288@dgii.com>you write:
  > It's definitely defined on OpenServer.  When I disassemble
  > the binary, I can see the call to __de
OK.  'twas just a thought.

  > I don't think it's falling through.  It looks like the problem is that
  > we're in an atexit() function (__do_global_dtors_aux) and it's calling 
  > the destructor and the destructor is calling exit.   Since exit() will
  > rip through the atexit() functions, isn't this bad?
Hmmm, I don't know enough about the language to know how this is supposed
to be handled.

Anyone know what's supposed to happen if, while running global dtors
a dtor itself calls exit, which starts the process of runing global
dtors again....


  > begin slight tangent...
  > 
  > If I change '-g0' to '-g', it dies during the build:
  > 
  > ./xgcc -B./  -DIN_GCC    -O2 -g -I./include  -I. -I../../egcs-971023/gcc -I
  > ../..
  > /egcs-971023/gcc/config  -g \
  >   -finhibit-size-directive -fno-inline-functions -fno-exceptions  \
  >   -c ../../egcs-971023/gcc/crtstuff.c -DCRT_BEGIN -o crtbegin.o
  > /usr/tmp/cca003Pz.s:279:defined relocatable values from the same section re > quired, op -
Bummer.  I suspect this is the funky way it we switch sections under
gcc's nose in crtstuff.

Almost makes we wonder if we should be using section attributes to do
the switching (which gcc knows how to emit proper debug symbols for).


  > Building crtstuff with this level of debugging makes the 
  > backtrace more clearly frightening.
Assuming (of course) that gdb is telling us the truth.  The reason
I say that is __do_lobal_dtors_aux doesn't directly call exit 
(unless it's on the dtor list).  If it's being called from an object's
dtor, then we know that gdb's lying because frames are missing.

But I think you've hit the root of the problem -- it looks like we're
calling exit more than once, which seems to do bad things.


jeff