Mail Archives: cygwin/2000/11/28/17:36:49
On Tue, Nov 28, 2000 at 04:59:35PM -0500, Patrick Doyle wrote:
>I am certain I have seen this on the mailing list before, but I cannot
>seem to find it. Could somebody please summarize tips for debugging
>cygwin1.dll. I have several specific questions. If somebody would care
>to answer them, I would be very grateful.
>
>1) Do all of the various _printf calls in the source (debug_printf(),
>syscall_printf, etc...) wend their way to strace, or do they go
>somewhere else? If they go somewhere else, how can I capture them?
Look at winsup/cygwin/include/sys/strace.h. This is where most of the
foo_printf calls are defined.
"grep is your friend"
>2) If I wanted to step into cygwin calls with GDB, (how) can I do that?
You set breakpoints on line numbers in cygwin. Either set a breakpoint
on main and wait for the DLL to be loaded or use the 'dll cygwin1'
command to preload the symbols for the DLL and then set breakpoints.
For some reason you can't set a breakpoint directly on a cygwin function
if you preload the symbols with 'dll cygwin1.dll'.
You can set a breakpoint on the first line of the function, though. So,
bp _read
won't work
but
bp syscalls.cc:204
will.
>3) I have successfully built cygwin1.dll from the CVS snapshot. If I
>want to try it, do I have to exit all of my cygwin apps, install it in
>/bin, and then restart my cygwin apps?
Yes.
>Or can I run a specific cygwin app using my new DLL without going
>through all of this?
Not safely. However, if you configure cygwin with --enable-debugging
this will produce a DLL which does not interfere as much with other
cygwin1.dll's on the system. I keep a gdb with its own stable
cygwin1.dll, built with --enable-debugging, sitting in its own directory
for debugging cases where cygwin1.dll is severely broken.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -