Re: Tracepoint enhancements

[Stan Shebs <stan@codesourcery.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