Re: [commit] Follow forks on HP-UX 11.xx

Re: [commit] Follow forks on HP-UX 11.xx

[Daniel Jacobowitz]

On Wed, Jul 20, 2005 at 03:25:35PM +0200, Mark Kettenis wrote:
> This patch adds back the feature that was lost when I revised the
> HP-UX native code.  There are still a few rough edges, but it works
> well enough to be useful.  So I committed this.  I'll try to polish up
> the testsuite and fix the bugs that uncovers.

Cool.  Two comments:

> +  if (follow_child)
> +    {
> +      inferior_ptid = ptid_build (fpid, flwpid, 0);
> +      detach_breakpoints (pid);
> +
> +      target_terminal_ours ();
> +      fprintf_unfiltered (gdb_stdlog, _("\
> +Attaching after fork to child process %ld.\n"), (long)fpid);
> +    }
> +  else
> +    {
> +      inferior_ptid = ptid_build (pid, lwpid, 0);
> +      detach_breakpoints (fpid);
> +
> +      target_terminal_ours ();
> +      fprintf_unfiltered (gdb_stdlog, _("\
> +Detaching after fork from child process %ld.\n"), (long)fpid);
> +    }

For GNU/Linux I recently moved these printouts to debug only.  No one
really seems to want to see them unless they already have a catchpoint.

And, the testcases for following vfork all rely on following exec.  I
haven't enabled them, or that feature, because the current user
interface for following exec is so awful - it silently changes which
binary you're debugging, messes up configured breakpoints, etc etc.

I don't recall if you have GNU/Linux systems to test on.  If not, let
me know if you have testsuite changes you want to check with the
GNU/Linux implementation of fork following.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [commit] Follow forks on HP-UX 11.xx

[Mark Kettenis]

   Date: Wed, 20 Jul 2005 09:34:57 -0400
   From: Daniel Jacobowitz <drow@false.org>

   On Wed, Jul 20, 2005 at 03:25:35PM +0200, Mark Kettenis wrote:
   > This patch adds back the feature that was lost when I revised the
   > HP-UX native code.  There are still a few rough edges, but it works
   > well enough to be useful.  So I committed this.  I'll try to polish up
   > the testsuite and fix the bugs that uncovers.

   Cool.  Two comments:

   > +  if (follow_child)
   > +    {
   > +      inferior_ptid = ptid_build (fpid, flwpid, 0);
   > +      detach_breakpoints (pid);
   > +
   > +      target_terminal_ours ();
   > +      fprintf_unfiltered (gdb_stdlog, _("\
   > +Attaching after fork to child process %ld.\n"), (long)fpid);
   > +    }
   > +  else
   > +    {
   > +      inferior_ptid = ptid_build (pid, lwpid, 0);
   > +      detach_breakpoints (fpid);
   > +
   > +      target_terminal_ours ();
   > +      fprintf_unfiltered (gdb_stdlog, _("\
   > +Detaching after fork from child process %ld.\n"), (long)fpid);
   > +    }

   For GNU/Linux I recently moved these printouts to debug only.  No one
   really seems to want to see them unless they already have a catchpoint.

Hmm yes, spamming the output while following the output doesn't really
make sense.  On the other hand, I think I'd like to see some
indication that GDB switched to following the child.  But we should
make sure that all platforms that support this print the same message.
We should really move the printing of those messages into platform
independent code.

   And, the testcases for following vfork all rely on following exec.  I
   haven't enabled them, or that feature, because the current user
   interface for following exec is so awful - it silently changes which
   binary you're debugging, messes up configured breakpoints, etc etc.

Hmm yes, I noticed that following execs is still disabled.  And yes
the code is a mess.  Any objection against removing it completely and
start afresh.

   I don't recall if you have GNU/Linux systems to test on.  If not, let
   me know if you have testsuite changes you want to check with the
   GNU/Linux implementation of fork following.

Trashed the old SuSE on my amd64 box recently, so I'm going to attempt
installing Fedora Core 4 on it.  You know whether that has a recent
enough kernel that has the fork/vfork following support in it?

Anyway, to what extent does following vfork work on Linux?  Does it
work flawlessly, or are there still some issues?

Mark

Re: [commit] Follow forks on HP-UX 11.xx

[Daniel Jacobowitz]

On Wed, Jul 20, 2005 at 06:29:18PM +0200, Mark Kettenis wrote:
> Hmm yes, spamming the output while following the output doesn't really
> make sense.  On the other hand, I think I'd like to see some
> indication that GDB switched to following the child.  But we should
> make sure that all platforms that support this print the same message.
> We should really move the printing of those messages into platform
> independent code.

Yes, we should, and the logic to control them.

>    And, the testcases for following vfork all rely on following exec.  I
>    haven't enabled them, or that feature, because the current user
>    interface for following exec is so awful - it silently changes which
>    binary you're debugging, messes up configured breakpoints, etc etc.
> 
> Hmm yes, I noticed that following execs is still disabled.  And yes
> the code is a mess.  Any objection against removing it completely and
> start afresh.

I'd rather not touch it until we figure out a better interface; it's
mildly useful as an example of where all the hooks would need to go. 
Unless it gets in the way, of course.

>    I don't recall if you have GNU/Linux systems to test on.  If not, let
>    me know if you have testsuite changes you want to check with the
>    GNU/Linux implementation of fork following.
> 
> Trashed the old SuSE on my amd64 box recently, so I'm going to attempt
> installing Fedora Core 4 on it.  You know whether that has a recent
> enough kernel that has the fork/vfork following support in it?

It should, unless RH's patches managed to break it; that's happened in
the past, but I think it won't happen again in 2.6.x.  Should be fine.

> Anyway, to what extent does following vfork work on Linux?  Does it
> work flawlessly, or are there still some issues?

I believe there's a nasty bit if you try to kill both processes while
stopped at a vfork catchpoint, where you'll end up with a zombie.  I
haven't tried to reproduce that in at least a year, though, so it may
be gone now.  Otherwise it works quite just fine.

-- 
Daniel Jacobowitz
CodeSourcery, LLC