Re: [commit] Follow forks on HP-UX 10.20

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

   Date: Mon, 25 Jul 2005 18:19:44 -0400
   From: Daniel Jacobowitz <drow@false.org>

   On Tue, Jul 26, 2005 at 12:12:28AM +0200, Mark Kettenis wrote:
   > Finally, the goal of this excercise.  The code is also going to be
   > used on OpenBSD when I get the necessary kernel stuff committed.  It
   > doesn't do follow-vfork yet.  HP-UX 10.20 doesn't really allow you to
   > do anything with a vforked child until it execs.  So follow-vfork
   > isn't useful until follow-exec is properly implemented.
   > 
   > Committed,

   I'm not really sure this is in the right place.  Good, you're going to
   implement the HP/UX ptrace interface on OpenBSD also.  But even then
   it'll be HP/UX and OpenBSD specific.  Why can't they inherit from
   inf-ptrace.c instead of adding ifdefs to this file?  Isn't that the
   point of target inheritance - to avoid having code in the "base
   classes" which is only useful on a few targets?

I considered doing this, but I didn't see a way to do this properly
without violating two other "design principles":

1. The #ifdef PT_GET_PROCESS_STATE is essentially interleaved with the
   rest of the code.  This is especially true for the fork following
   code that I didn't commit (yet).  Seperating things would almost
   certainly lead to code duplication.

2. Creating a HP-UX and OpenBSD specific target vector would make
   autocomatic detection of the availibility of the necessary
   interfaces complicated.  This is especially important for OpenBSD,
   where older versions don't have the necessary interfaces, and where
   we have an instantiation for the target vector for every supported
   hardware platform.  So this:

   > @@ -471,6 +588,9 @@ inf_ptrace_target (void)
   >    t->to_files_info = inf_ptrace_files_info;
   >    t->to_kill = inf_ptrace_kill;
   >    t->to_create_inferior = inf_ptrace_create_inferior;
   > +#ifdef PT_GET_PROCESS_STATE
   > +  t->to_follow_fork = inf_ptrace_follow_fork;
   > +#endif
   >    t->to_mourn_inferior = inf_ptrace_mourn_inferior;
   >    t->to_thread_alive = inf_ptrace_thread_alive;
   >    t->to_pid_to_str = normal_pid_to_str;

   This in particular makes me think it's in the wrong place.

seems to be the right idiom from an autoconf standpoint.

So instead of trying to go for OO purity, I took a more pragmatic
approach.

If you really think the interleaved #ifdefs are obfuscating the code,
I think I can rework things a bit and create something a bit closer to
seperate target vectors.  But in order to avoid the problems in 1. and
2. I'd keep the stuff in inf-ptrace.c.

Mark