Debugging cygwin1.dll

Egor Duda
Mon Jan 15 07:26:00 GMT 2001


Saturday, 13 January, 2001 Trevor Forbes wrote:

TF> I have tried to debug cygwin1.dll with limited success. I am able to trace
TF> the source through the cygwin1.dll until "gdb itself" just stacks dumps with
TF> an access violation which then just reloads gdb (error_start).

TF> I have gdb and a debug cygwin1.dll in the same directory but not in my path.
TF> I run GDB from cmd.exe and then load the program under test and set the
TF> breakpoints as usual.

you  can  use strace utility, which doesn't depend on cygwin1.dll, and
put  appropriate debug_printf()'s to the code in question. if you want
to  use  gdb, you can perform a following trick: put stable version of
cygwin1.dll  and stable version of gdb.exe somewhere out of your path,
say to c:\cygdeb\ then, create c:\cygdeb\run_debugger.cmd

============= run_debugger.cmd =============
rem this set instructs cygwin1.dll to use separate shared memory area
rem and thus not interfere with "main" instance if cygwin1.dll
rem see winsup/ for details
cd \cygdeb
gdb.exe %1 %2

then set CYGWIN=%CYGWIN% error_start=c:\cygdeb\runb_debugger.cmd

TF> Is there a more reliable method of debugging the cygwin1.dll?

TF> Would I be better to remotely debug cygwin from my Linux box? Is there any
TF> gdb stub to achieve this?

hmm,  i  suppose  it's  possible  to port gdbserver to mingw, though i
can't say whether it would be hard or not.

alternatively,  you  can  link  gdb/i386-stub.o  in  your application,
supply exceptionHandler(), putDebugChar() and getDegugChar() functions
to communicate to remote gdb.

Egor.   ICQ 5165414 FidoNet 2:5020/496.19

Want to unsubscribe from this list?
Check out:

More information about the Cygwin mailing list