This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: Actual support for tracing forks on GNU/Linux
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb-patches at sources dot redhat dot com, msnyder at redhat dot com, kettenis at gnu dot org
- Date: Thu, 24 Jul 2003 14:48:49 -0400
- Subject: Re: RFA: Actual support for tracing forks on GNU/Linux
- References: <20030618232942.GA982@nevyn.them.org> <20030628163444.GB9716@nevyn.them.org> <20030709215713.GA25331@nevyn.them.org>
On Wed, Jul 09, 2003 at 05:57:13PM -0400, Daniel Jacobowitz wrote:
> On Sat, Jun 28, 2003 at 12:34:44PM -0400, Daniel Jacobowitz wrote:
> > On Wed, Jun 18, 2003 at 07:29:42PM -0400, Daniel Jacobowitz wrote:
> > > This patch enables "catch fork" and "set follow-fork-mode child" for fork().
> > >
> > > Other things from my working directory that doesn't include:
> > > - vfork support - I'll do that separately once this in
> > > - exec support - the code is still a mess
> > > - exit event support - i.e. stopping the process just before it exits,
> > > to take a look around - this confuses GDB very badly
> > > - gdbserver support for any of the above
> > > - enabling the testsuite checks for this - even worse of a mess
> > > I hope to get at least native vfork support into GDB 6.0.
> > >
> > > This patch works by adding a hook every time we attach to an LWP or fork a
> > > new LWP, to set tracing flags on it. We enable event reporting for fork()
> > > [which requires ~ 2.5.34 kernel; I heard that one of RH's backport kernels
> > > included this, but I don't know if it still does.] Then, when we get a
> > > fork, we end up attached to both parent and child. We remove breakpoints in
> > > whichever one we don't care about, and then we detach it.
> > >
> > > This both lets us choose which one to trace, and also fixes the problem
> > > where breakpoints would be left in the inferior after it forked, causing the
> > > child to die with SIGTRAP.
> > >
> > > I had to override kill_inferior, for an issue discovered in testing: when
> > > we're stopped with both processes attached, we have to make sure to kill
> > > them both. We have to deal with this because the user could "catch fork",
> > > and when they see the fork decide which one to debug.
> > >
> > > I think that's everything. I'd like at least a nod from the threading
> > > maintainers, since I had to hook into lin-lwp.c. OK?
>
> Ping? If neither of our thread maintainers feels comfortable
> commenting on this patch I'm willing to approve it myself, but I'd
> prefer a comment from the maintainers of lin-lwp.
Ping.
> > > 2003-06-18 Daniel Jacobowitz <drow@mvista.com>
> > >
> > > * config/i386/nm-linux.h (LINUX_CHILD_POST_STARTUP_INFERIOR): Define.
> > > * config/nm-linux.h (linux_enable_event_reporting)
> > > (linux_handle_extended_wait, linux_child_post_startup_inferior): New
> > > prototypes.
> > > (CHILD_POST_STARTUP_INFERIOR, CHILD_POST_ATTACH, CHILD_FOLLOW_FORK)
> > > (KILL_INFERIOR): Define.
> > > * i386-linux-nat.c (child_post_startup_inferior): New function.
> > > * i386-nat.c (child_post_startup_inferior): Wrap in #ifdef.
> > > * infptrace.c (kill_inferior): Wrap in #ifdef.
> > > * lin-lwp.c (lin_lwp_attach_lwp): Call child_post_attach after
> > > attaching to each LWP.
> > > (child_wait, lin_lwp_wait): Call linux_handle_extended_wait.
> > > (init_lin_lwp_ops): Fill in some more operations.
> > > * linux-nat.c (linux_enable_event_reporting): New function.
> > > (child_post_attach, linux_child_post_startup_inferior)
> > > (child_post_startup_inferior, child_follow_fork)
> > > (linux_handle_extended_wait, kill_inferior): New functions.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer