Does anyone have any insight into this problem? I'm compiling gcc-3.3.2 on cygwin as a cross compiler. I'm playing around with machine descriptions, so I expect core dumps to happen when the cross compiler runs. The core dumps will be useful in figuring out how and where I screwed up the machine descriptions.
I've set the environment variable CYGWIN=error_start=C:\cygwin\bin\dumper.exe so that I get core files on abort. I also had to comment out the abort defines in tree.h and rtl.h, and also change toplev.c so that the SIGABRT signal calls the default signal handler instead of the non-core producing crash_signal. If I didn't do this, I wouldn't get any core dump at all when abort() is called.
So I get all the way to compiling the various parts of libgcc2, and I get a core dump cc1.exe.core. I run gdb on cc1.exe, and I get this output:
$ gdb C:/cygwin/home/Ek/build2/gcc/cc1.exe cc1.exe.core
GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
warning: core file may not match specified executable file. 00400000:C:/cygwin/home/Ek/build2/gcc/cc1.exe (symbols previously loaded) #0 0x7ffe0304 in ?? () Breakpoint 1 at 0x48cfa6: file ../../gcc-3.3.2/gcc/diagnostic.c, line 1376. Breakpoint 2 at 0x5c2670 Breakpoint 3 at 0x5c2350 (gdb) where #0 0x7ffe0304 in ?? () #1 0x77f5c534 in ntdll!ZwWaitForSingleObject () #2 0x77e7a62d in WaitForSingleObjectEx () #3 0x00000778 in ?? ()
So my question is, where is all the useful information? Why doesn't the stack trace show where the abort happened?
Any help would be appreciated.
Thanks!
--Rob
