Mon Jan 15 07:26:00 GMT 2001
Saturday, 13 January, 2001 Trevor Forbes firstname.lastname@example.org 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/shared.cc for details
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. mailto:email@example.com ICQ 5165414 FidoNet 2:5020/496.19
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin