This is the mail archive of the
mailing list for the Cygwin project.
Re: Debugging sub-processes with gdb
- From: LRN <lrn1986 at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 14 May 2014 19:34:17 +0400
- Subject: Re: Debugging sub-processes with gdb
- Authentication-results: sourceware.org; auth=none
- References: <f5boaz0e6qb dot fsf at troutbeck dot inf dot ed dot ac dot uk> <20140514152505 dot GB6620 at ednor dot casa dot cgf dot cx>
-----BEGIN PGP SIGNED MESSAGE-----
On 14.05.2014 19:25, Christopher Faylor wrote:
> On Wed, May 14, 2014 at 04:10:36PM +0100, Henry S. Thompson wrote:
>> I'm trying to debug a problem with xemacs that involves the child
>> process forked when you execute M-x shell.
>> None of the mechanisms in the gdb documentation for choosing to step
>> into the child process (instead of the parent) after a fork() seem to
>> work for me. That is, in particular, setting follow-for-mode to child
>> still leaves me in the parent after stepping over a fork().
>> Setting detach-on-fork to 'off' also seems to have no effect.
>> Have I misunderstood something, or does this aspect of gdb just not work
>> under cygwin (x86_64, 1.7.29-2)?
> Debugging subprocesses doesn't work for Windows gdb. Sorry.
> If you have control over the code you could have it print a pid, wait, and
> then attach to it with gdb. That works.
What i do in these cases:
1) Find the call to CreateProcess() that spawns the child (if it uses some
kind of _spawn() instead, you're screwed)
2) Add a breakpoint (b1) before the call and a breakpoint (b2) after the call
3) commands b1
set createprocessflags=createprocessflags | 4
(replace createprocessflags with the variable used to hold the flags)
4) commands b2
(replace processinfo with the variable used to hold handles and IDs for
spawned child process/thread)
This way all processes will be spawned in suspended state (that's what 4 is
for), and gdb will stop on a breakpoint after the call to wait for you to
figure out what to do. If you want to debug the child, re-attach gdb to it,
or launch a new gdb instance and attach that one. In either case, add a
breakpoint at main, then continue. Once that is done, use ProcessHacker (or
anything similar) to Resume the suspended child process. If the child itself
spawns children you want to debug, repeat these steps there as well.
I was able to debug ld.exe this way (it is spawned by collect2.exe, which is
spawned by gcc.exe).
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
-----END PGP SIGNATURE-----
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple