Re: HP catchpoint code

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Aug 13, 2002 at 03:39:59PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > I'm working on GNU/Linux support for fork and exec catchpoints.  The kernel
> > code I needed (well, wanted; it's possible without, just bloody awkward) was
> > straightforward, and I already have strace using it.  When I started digging
> > into the GDB code for it I got a little quagmired, though.
> > 
> > My plan is to completely ignore the existing support for this feature.  An
> > astute code reviewer will note that it doesn't work anywhere but HP/UX; the
> > code to initialize it is only present for ttrace.  The target-independent
> > portions of it are completely dependent on the ttrace model.  I'd like to
> > rename, or at least recomment, TARGET_WAITKIND_FORKED (and VFORKED, possibly
> > EXECD, haven't gotten to that one yet) to indicate their HP-specificness and
> > add some new waitkinds for the different model I'm using.  Any objections?
> 
> Those were introduced by TIHPM; I gather that HP designed them with
> the intention of doing things right --- generic mechanisms built on an
> HP-specific layer --- but they never discussed the design with the
> rest of the GDB scene, and the supposedly generic stuff didn't end up
> as generic as it should have been.
> 
> (To be fair, I think HP did the work in the Old Bad Days, when `the
> rest of the GDB scene' was a private list within Cygnus.  There was a
> public list, but it wasn't very active --- who wants to have a design
> discussion in a forum where there is clearly nothing going on?)
> 
> I'm uncomfortable just renaming the old stuff and moving on --- if
> we're going to replace it with something better, I'd like to have some
> plan for eventually getting rid of the old stuff altogether.  For
> example, would it make sense to set a deadline by which the old stuff
> would go away?  It looks like the PA, and thus ttrace, is scheduled to
> be obsoleted; we could obsolete the old catchpoint stuff at that
> point, too, without repercussions beyond what the obsoleting will
> cause by itself.
> Could you talk more about the new catchpoint implementation you have
> in mind?  (Maybe you did and I missed it --- sorry if so.)

When I posted that, I was neck-deep implementing the kernel code to
support the new interface.  It turned out rather different than I
expected!  I'll still need some changes, but not as many as I feared,
so I'm reusing the code that's there.

I'm almost (not quite) intrigued enough to investigate the HP
mechanisms; they made some bizarre decisions in the implementation and
I can't figure out why.  For instance, in when breakpoints are detached
when following vforks.  In GNU/Linux you need the breakpoints removed
while the vfork is running, no matter which process you're following. 
Either you follow the parent, and you have to remove breakpoints until
the exec happens (which means you must hold on to the child until it
execs!).  Or you follow the child, in which case you can't resume the
parent until the child has exec'd anyway, and you need to detach
breakpoints from it before resuming it.  That's where most of my
pain is coming from right now.

So let's plan to hold on to it for now.  I may strip out some of its
complexity after the PA is obsoleted, if no one expresses interest in
reviving that port in a pretty timely fashion.  I can't fix bugs in
something that makes no sense to me :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer