Dan Kegel wrote:
Sadly, error_start didn't seem to be able to start gdb:
Thanks to Igor for pointing out that error_start must be a
DOS path. Here's what I see once I correct that:
$ export CYGWIN=error_start:C:\\cygwin\\bin\\gdb.exe
$ make
...
(gdb) bt
#0 0x77f75a59 in ntdll!DbgUiConnectToDbg ()
from /cygdrive/c/WINDOWS/System32/ntdll.dll
#1 0x77f5f31f in ntdll!KiUserCallbackDispatcher ()
from /cygdrive/c/WINDOWS/System32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()
#5 0x006effd0 in ?? ()
#6 0x82ba40e8 in ?? ()
#7 0xffffffff in ?? ()
#8 0x77fa88f0 in wcstombs () from /cygdrive/c/WINDOWS/System32/ntdll.dll
Unfortunately, that's also about what I see when I do
$ export CYGWIN=error_start:C:\\cygwin\\bin\\gdb.exe
$ ./a.exe
where a.exe is the following compiled with cygwin's gcc:
#include <stdio.h>
int main(int argc, char **argv)
{
int *x;
x = 0;
printf("Null is %d\n", *x);
}
Looking at the other two threads (why are there three?)
doesn't help.
The stackdump file seems more informative than the gdb
started with error_start. Has anyone used gdb from
this context with success lately? gdb has no problem
with a.exe when run normally.
- Dan
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
