This is the mail archive of the
mailing list for the Cygwin project.
Re: 1.5.18: ld command generates stackdump
PS = Pete Stieber
PS>>> Do I also need to build a debug version of the cygwin DLL?
BD = Brian Dessent
BD>>It would help, since otherwise backtraces will only have raw
BD>> addresses. Note that the cygwin configure script[*] has a
BD>> --enable-debugging switch, but this is for enabling lots of
BD>> runtime consistency checks and extra verbosity -- it is not
BD>> meant for enabling debug symbols, which you
BD>>should get by default.
CF> Is this dying in the cygwin DLL? I suspect that it isn't.
CF> The stackdump file would show if it is, as would using
CF> CYGWIN error_start setting that I mentioned previously.
CF> I don't think there's any reason to build a debugging
CF> version of cygwin unless the problem points to the
CF> cygwin DLL.
Keeping in mind that I am having problems building binutils (mentioned
in a recent reply to Brian's post), here is the back trace from a
stripped version of ld using the technique you suggested.
Attaching to program `/bin/ld.exe', process 3248
[Switching to thread 3248.0x850]
#0 0x7c901231 in ntdll!DbgUiConnectToDbg ()
#1 0x7c9507a8 in ntdll!KiIntSystemCall ()
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()
#5 0x1941ffd0 in ?? ()
#6 0x3531283a in ?? ()
#7 0xffffffff in ?? ()
#8 0x7c90ee18 in strchr () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#9 0x7c9507c8 in ntdll!KiIntSystemCall ()
#10 0x00000000 in ?? () from
This is probably useless, but just wanted to indicate I'm not ignoring
your advice. It is greatly appreciated.
Thanks for the help Christopher,
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html