[RFC] "actionpoints"?

[RFC] "actionpoints"?

[Stan Shebs]

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.  We haven't dealt 
with it consistently so far, sometimes writing code to specifically say 
"tracepoint" when all the objects are tracepoints, sometimes saying "or" 
with several types, and sometimes relying on GDB's overloading of 
"breakpoint" to mean both stopping places and anything that uses the 
breakpoint.c infrastructure.

Although we've been doing the overloading for a long time, it's really 
abusing our terminology, and has to be confusing to users.

It turns out there is a generic term available - "actionpoint".  It 
originally comes from TotalView I think, and was adopted into the HPD 
(high performance debugger) spec back in the 90s.

A plus is that the term is sufficiently vague that it is sensible for 
watchpoints, catchpoints, tracepoints, breakpoints, and the rest of the 
menagerie, including future ideas we haven't thought of yet.  A minus is 
that it means having to teach an unfamiliar term to users, and it 
entails a certain amount of hacking up the manual.

There is also the risk that some (and you know who you are :-) ) will 
feel an overwhelming urge to rename source code to actionpoint.c, struct 
actionpoint, etc, which I *don't* want to do - it's a lot of busywork 
that doesn't directly help the user.  Right now I just want to think 
about how to give good feedback to users; should we introduce a new 
term, continue using "breakpoint", concoct phrases with "/" and "or", or 
do something else entirely?

Stan

Re: [RFC] "actionpoints"?

[Eli Zaretskii]

> Date: Fri, 15 Jan 2010 16:22:35 -0800
> From: Stan Shebs <stan@codesourcery.com>
> 
> It turns out there is a generic term available - "actionpoint".  It 
> originally comes from TotalView I think, and was adopted into the HPD 
> (high performance debugger) spec back in the 90s.
> 
> A plus is that the term is sufficiently vague that it is sensible for 
> watchpoints, catchpoints, tracepoints, breakpoints, and the rest of the 
> menagerie, including future ideas we haven't thought of yet.  A minus is 
> that it means having to teach an unfamiliar term to users, and it 
> entails a certain amount of hacking up the manual.

Not only the manual, but also some commands, such as "info break".
They will have to be renamed.

I don't necessarily object, although personally it sounds a bit gross
to me.

Re: [RFC] "actionpoints"?

[Stan Shebs]

Eli Zaretskii wrote:
>> Date: Fri, 15 Jan 2010 16:22:35 -0800
>> From: Stan Shebs <stan@codesourcery.com>
>>
>> It turns out there is a generic term available - "actionpoint".  It 
>> originally comes from TotalView I think, and was adopted into the HPD 
>> (high performance debugger) spec back in the 90s.
>>
>> A plus is that the term is sufficiently vague that it is sensible for 
>> watchpoints, catchpoints, tracepoints, breakpoints, and the rest of the 
>> menagerie, including future ideas we haven't thought of yet.  A minus is 
>> that it means having to teach an unfamiliar term to users, and it 
>> entails a certain amount of hacking up the manual.
>>     
>
> Not only the manual, but also some commands, such as "info break".
> They will have to be renamed.
>   
I don't think that one can be changed, it's just too heavily used in its 
current form.  That doesn't preclude adding new synonyms, and maybe 
something like "info just-breakpoints" if anyone really wants that.

Stan

Re: [RFC] "actionpoints"?

[Eli Zaretskii]

> Date: Mon, 18 Jan 2010 08:51:03 -0800
> From: Stan Shebs <stan@codesourcery.com>
> CC: Stan Shebs <stan@codesourcery.com>, gdb@sourceware.org
> 
> > Not only the manual, but also some commands, such as "info break".
> > They will have to be renamed.
> >   
> I don't think that one can be changed, it's just too heavily used in its 
> current form.  That doesn't preclude adding new synonyms, and maybe 
> something like "info just-breakpoints" if anyone really wants that.

Well, granted, I didn't mean to break back-compatibility, so "info
break" will have to stay, even if only as an alias.

Re: [RFC] "actionpoints"?

[Frank Ch. Eigler]

Stan Shebs <stan@codesourcery.com> writes:

> [...]
> Although we've been doing the overloading for a long time, it's really
> abusing our terminology, and has to be confusing to users.

Would a new *single* term for the variety of possibilities make the
situation less confusing?

> It turns out there is a generic term available - "actionpoint".  [...]

In systemtap, we use the term "probe point" to identify a place (in
code) or a time (asynchronous event).  What happens at those points --
tracing or modifying variables or whatnot -- is programmable, and
distinct from how the probe point was named.

> A plus is that the term is sufficiently vague that it is sensible
> for watchpoints, catchpoints, tracepoints, breakpoints, and the rest
> of the menagerie, including future ideas we haven't thought of yet.
> [...]

This does not sound like a plus to me.  A good term is *clear*.


- FChE

Re: [RFC] "actionpoints"?

[Stan Shebs]

Frank Ch. Eigler wrote:
> Stan Shebs <stan@codesourcery.com> writes:
>
>   
>> A plus is that the term is sufficiently vague that it is sensible
>> for watchpoints, catchpoints, tracepoints, breakpoints, and the rest
>> of the menagerie, including future ideas we haven't thought of yet.
>> [...]
>>     
>
> This does not sound like a plus to me.  A good term is *clear*.
>
>   
Heh - "vague" is poor phrasing, I just meant that an all-encompassing 
term would ideally connote that wider compass, without carrying some 
other kind of more specific meaning.  By that standard, "actionpoint" is 
not ideal, because we already use "action" to refer to what tracepoints 
when hit, and similarly for "eventpoint", because we do use "event" in 
GDB, though in only a couple restricted contexts.  "*point" is perhaps 
technically most correct, although but as a non-word it presents 
difficulties, for instance when mentioning it over the phone. :-)

Stan

Re: [RFC] "actionpoints"?

[Joel Brobecker]

> 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

Re: [RFC] "actionpoints"?

[Eli Zaretskii]

> Date: Mon, 18 Jan 2010 10:43:48 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb@sourceware.org
> 
> I don't think we should change all the user interface (eg: info
> breakpoints") where it is already clear what the output is about.

??? How is it clear?  "info break" displays all ``actionpoints''
regardless of their kind, last time I tried.  Am I missing something?

Re: [RFC] "actionpoints"?

[Joel Brobecker]

> > I don't think we should change all the user interface (eg: info
> > breakpoints") where it is already clear what the output is about.
> 
> ??? How is it clear?  "info break" displays all ``actionpoints''
> regardless of their kind, last time I tried.  Am I missing something?

Yeah, well, the command is misnamed. We can introduce aliases and
do a gradual transition, if we want. But I think that'd bring very
little actual benefit.  However, I don't think that this is enough
for us to give up on the idea. We have a chance to:

  1. Improve the code - the current overload of "breakpoint" in
     various places such as to_can_use_hw_breakpoint is just misleading,
     and "point" just requires extra thinking every time I read it.
     It's misleading too. "*point" is less misleading, but how do you
     write *point in a C identifier?

  2. Improve the documentation and error messages.

If we introduce a new, well defined and documented terminology,
that says ``for GDB, actionpoint means any of [...]'', then we can
start using it. If, people come back to us, and ask: <<how come
this command is named "info break">>, we can certainly explain
that this is historical, and that we don't want to change it because
it's been used for 20 years.

We can't fix it all to make it perfect, but I think that introducing
a new term would still make it better.

-- 
Joel

Re: [RFC] "actionpoints"?

[Stan Shebs]

Joel Brobecker wrote:
>>> I don't think we should change all the user interface (eg: info
>>> breakpoints") where it is already clear what the output is about.
>>>       
>> ??? How is it clear?  "info break" displays all ``actionpoints''
>> regardless of their kind, last time I tried.  Am I missing something?
>>     
>
> Yeah, well, the command is misnamed. We can introduce aliases and
> do a gradual transition, if we want.
As a small quasi-data-point, in my tracepoint tinkering, I noticed that 
once breakpoints and tracepoints were merged, I drifted into the habit 
of doing "info b" even when I'm only wanting to see the list of 
tracepoints.  That might just be because the list has tended to be 
short, only around five action/event/x/*points in all; I imagine that 
filtering by type gets more interesting at 10 and up, as happens with 
rbreak and the like.

Stan

Re: [RFC] "actionpoints"?

[Pedro Alves]

On Monday 18 January 2010 18:53:21, Stan Shebs wrote:

> As a small quasi-data-point, in my tracepoint tinkering, I noticed that 
> once breakpoints and tracepoints were merged, I drifted into the habit 
> of doing "info b" even when I'm only wanting to see the list of 
> tracepoints.  That might just be because the list has tended to be 
> short, only around five action/event/x/*points in all; I imagine that 
> filtering by type gets more interesting at 10 and up, as happens with 
> rbreak and the like.

Same here.

I've always missed a way to get a list of _only_
breakpoints (points in the program where execution should break),
not including watchpoints, catchpoints, whatnot.  I'm now wishing
more for this ever since we merged tracepoints and breakpoints.

Another missing functionality I often miss is way to delete
all breakpoints, but _only_ breakpoints --- leave watchpoints, 
tracepoints, etc.

Note:

 "delete breakpoints" - deletes everything (breakpoints, tracepoints,
watchpoints, whatnot).

 "delete tracepoints" - deletes only tracepoints.

 There's no "delete watchpoints", for example.

I find this inconsistenty confusing.  If we could have
a new "delete actionpoints" command, we could re-alias "delete" to
delete all kinds of action points, and then have "delete
breakpoints" delete only breakpoints.

-- 
Pedro Alves

Re: [RFC] "actionpoints"?

[Stan Shebs]

Joel Brobecker wrote:
>> 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.
>   
"eventpoint" is a good candidate.  Googling shows it in VxWorks and the 
old VAX/VMS debugger - and a couple dozen appearances in GDB sources(!); 
most likely inherited from HP code, which was partly written by ex-DEC 
people...  To me "eventpoint" has a slight downside in that it is used 
in several OS debugging/monitoring tools, tied to various notions of 
system-level "event", so the manual would have to emphasize that our 
notion of eventpoint is not OS-related in any way.  But that doesn't 
seem too difficult to explain.

Stan

Re: [RFC] "actionpoints"?

[Pedro Alves]

I vote for "actionpoint".  It's standardized by HPD, for what
that's worth, and used by at least one other major debugger to
represent the same thing being proposed here.  This is just a
name afterall, people get used to all kinds of names with no
effort, even though in this case "action point" actually makes
sense.

-- 
Pedro Alves

Re: [RFC] "actionpoints"?

[Daniel Jacobowitz]

On Mon, Jan 18, 2010 at 07:04:25PM +0000, Pedro Alves wrote:
> I vote for "actionpoint".  It's standardized by HPD, for what
> that's worth, and used by at least one other major debugger to
> represent the same thing being proposed here.

For what it's worth, I like this too.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] "actionpoints"?

[Frank Ch. Eigler]

Stan Shebs <stan@codesourcery.com> writes:

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

> "eventpoint" is a good candidate.k

I don't have a dog in this fight, but how about plain "breakpoint" to
identify any code spot or event where the target process's normal
control flow is broken?  In other words, make that the cover term for
naming such abstract locations.  Then classify into different possible
breakpoint actions: "stop breakpoint", "trace breakpoint", "watch
breakpoint".

- FChE