Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@zenia.red-bean.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb@sources.redhat.com
Subject: Re: HP catchpoint code
Date: Tue, 13 Aug 2002 13:49:00 -0000	[thread overview]
Message-ID: <vt2adnqze5c.fsf@zenia.red-bean.com> (raw)
In-Reply-To: <20020812153334.GA30891@nevyn.them.org>


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


  reply	other threads:[~2002-08-13 20:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-12  8:33 Daniel Jacobowitz
2002-08-13 13:49 ` Jim Blandy [this message]
2002-08-13 14:41   ` Daniel Jacobowitz
2002-08-13 14:59     ` Andrew Cagney
2002-08-14  7:06       ` Carlos O'Donell
2002-08-14  7:13         ` Daniel Jacobowitz
2002-08-14  9:21           ` Carlos O'Donell
2002-08-15 18:53             ` Andrew Cagney
2002-08-16  5:46               ` Carlos O'Donell
2002-10-18 15:16       ` Daniel Jacobowitz
2002-10-21 12:08         ` Andrew Cagney
2002-10-21  8:33           ` Daniel Jacobowitz
2002-10-21 12:08             ` Andrew Cagney
2002-10-21 12:13               ` Daniel Jacobowitz
2002-10-22  8:17                 ` Andrew Cagney
2002-11-07 15:24             ` Andrew Cagney
2002-11-07 19:21               ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=vt2adnqze5c.fsf@zenia.red-bean.com \
    --to=jimb@zenia.red-bean.com \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox