This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: HP catchpoint code


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.)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]