Re: Tracepoint enhancements

[Stan Shebs <stan at codesourcery dot com>]

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. We get tracepoint conditions via "condition" 
and "trace ... if" then. Not clear if "info tracepoints" should stick 
around as a subset of "info breakpoints".

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.

Stan