Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-patches@sources.redhat.com, msnyder@redhat.com
Subject: Re: RFA: Actual support for tracing forks on GNU/Linux
Date: Sat, 28 Jun 2003 16:35:00 -0000	[thread overview]
Message-ID: <20030628163444.GB9716@nevyn.them.org> (raw)
In-Reply-To: <20030618232942.GA982@nevyn.them.org>

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?

> 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


  reply	other threads:[~2003-06-28 16:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-18 23:29 Daniel Jacobowitz
2003-06-28 16:35 ` Daniel Jacobowitz [this message]
2003-07-09 21:57   ` Daniel Jacobowitz
2003-07-24 18:48     ` Daniel Jacobowitz
2003-08-10 16:11       ` Mark Kettenis
2003-08-17 18:22         ` Daniel Jacobowitz
2003-08-18  9:09           ` Michal Ludvig
2003-08-18 12:59             ` Daniel Jacobowitz
2003-08-18 13:11               ` Michal Ludvig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030628163444.GB9716@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox