Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Stan Shebs <stan@codesourcery.com>
Cc: gdb@sourceware.org
Subject: Re: [RFC] "actionpoints"?
Date: Mon, 18 Jan 2010 06:44:00 -0000	[thread overview]
Message-ID: <20100118064348.GA1914@adacore.com> (raw)
In-Reply-To: <4B5106CB.5060204@codesourcery.com>

> One of the issues that has come up regularly in our tracepoint work
> is what GDB's messages to the user should say when they are
> referring to various combinations of tracepoints and breakpoints.

I like the idea of having a term that means either breakpoint/watchpoint/
tracepoint, etc. How about "eventpoint"? "actionpoint" sounds OK to me too.

We can officially document that term to explain to the user what it
means and start using it in our error messages.  I would also like us
to start using it in lieu of "point", or "*point" as I'm starting to
see. "point" has been used in gdbserver for a while, and might be
already established enough to be understandable, but I just find
that it always slows me down when I read this term, it's never fluid.
"eventpoint" or "actionpoint" would be better.

I don't think we should change all the user interface (eg: info
breakpoints") where it is already clear what the output is about.
If it's about breakpoints only, we should continue using the more
precise term of "breakpoint", etc.

However, error or informational messages could be easier to read,
IMO, if we used a standard term instead if
breakpoint/watchpoint/tracepoint or even just "point".

Incidentally, there is a target_ops routine "to_can_use_hw_breakpoint"
which is meant to be used to query the target about support for any
of the actionpoint/eventpoint kinds.  The purpose of this routine would
be clearer if renamed to "to_can_use_hw_eventpoint".

Did I mention that I'm partial to "eventpoint"? ;-) I think it's because
it's the terminology used on VxWorks, but I am not sure.  In any case,
actionpoint source just as nice, and either is a fine choice to me.

-- 
Joel


  parent reply	other threads:[~2010-01-18  6:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-16  0:22 Stan Shebs
2010-01-16  7:57 ` Eli Zaretskii
2010-01-18 16:51   ` Stan Shebs
2010-01-18 18:08     ` Eli Zaretskii
2010-01-16 13:51 ` Frank Ch. Eigler
2010-01-18 17:09   ` Stan Shebs
2010-01-18  6:44 ` Joel Brobecker [this message]
2010-01-18 17:54   ` Eli Zaretskii
2010-01-18 18:18     ` Joel Brobecker
2010-01-18 18:53       ` Stan Shebs
2010-01-18 19:08         ` Pedro Alves
2010-01-18 18:44   ` Stan Shebs
2010-01-18 19:04     ` Pedro Alves
2010-01-21 21:24       ` Daniel Jacobowitz
2010-01-18 19:35     ` Frank Ch. Eigler

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=20100118064348.GA1914@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb@sourceware.org \
    --cc=stan@codesourcery.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