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

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

   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