Re: Tracepoint enhancements

[Vladimir Prus <vladimir at codesourcery dot com>]

On Wednesday 05 November 2008 00:16:33 Stan Shebs wrote:
> Michael Snyder wrote:
> > Vladimir Prus wrote:
> >> Michael Snyder wrote:
> >
> >>> One more thing, only vaguely related...
> >>>
> >>> I've thought that if we had the ability to attach an expression
> >>> (in pcode such as we use for tracepoints) to a conditional breakpoint,
> >>> we could have the conditional evaluation be done on the target
> >>> rather than by gdb, which would be a big performance win for
> >>> conditional breakpoints or watchpoints.
> >>
> >> Yes. We want conditional tracepoints, and the condition would have to 
> >> be evaluated
> >> on the target. And if breakpoints and tracepoints are unified, both 
> >> breakpoints and
> >> tracepoints will benefit.
> >
> > Very good point.  OK, you've convinced me.
> I shall proceed on the assumption that we will make a tracepoint a kind 
> of breakpoint. This means we no longer need the special 
> enable/disable/delete commands. I think the original "trace" command 
> should remain as-is, and I'm also inclined to leave "actions" alone for 
> the moment, rather than try to merge with "commands"; while there could 
> be some useful unification, it seems like more of a sweeping change to 
> try to decide for every command, whether it could be part of a 
> tracepoint action or not. 

There's no need to do that. 'collect', 'while-stepping' and 'continue'
can be part of command set that is hardware-supported. Other commands do not.

>From MI standpoint, I disagree to having independent 'commands' and 'actions'
properties -- this makes no sense in the long run, and MI is not supposed to
be breaking behaviour at random, so we cannot implement 'actions' now, and
take it back later.

> Ignore counts vs passcounts still mystify me a bit. They seem 
> conceptually similar (modulo the sense inversion), but the documentation 
> for passcounts makes it seems as though one might expect all tracing and 
> all tracepoints to be disabled once a passcount is exceeded for any one 
> of them - and I see where that might be the desired behavior, vs the 
> per-breakpoint control of ignore counts.

Yeah, this is one bit that needs further design.

- Volodya