This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: egcs 10-31 and UnixWare
- To: acs at acm dot org
- Subject: Re: egcs 10-31 and UnixWare
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Sun, 09 Nov 1997 09:54:04 -0700
- cc: egcs at cygnus dot com, gcc2 at cygnus dot com, Ronald Joe Record <rr at sco dot com>, Robert Lipe <robertl at dgii dot com>
- Reply-To: law at cygnus dot com
In message <199711071702.MAA14022@honeydew.icd.teradyne.com>you write:
> I still can't build the recent egcs snapshots on UnixWare 2.1.2 (SVR4.2 MP).
> The most recent snapshot I successfully built was egcs-970910. I have tried
> many snapshots since then, including 10-31 and 11-05 and they all fail in
> the same way: the stage 1 compiler builds an executable which dumps core in
> __do_global_dtors_aux() on the way out.
Hmm, I must have missed something -- I thought we were getting screwed up
on the way in!
If we're indeed dying on the exit path, then I'd start to look at some of
the problems Robert Lipe recently ran into.
> Here's the backtrace:
> #0 0xbffb3783 in kill ()
> #1 0xbffe3528 in abort ()
> #2 0x804853e in __do_global_dtors_aux ()
> #3 0x8048ffd in _fini ()
Can you do something like
x/50i __do_global_dtors_aux
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.
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.
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?
jeff