Re: Tracepoint enhancements

Stan Shebs
2008-11-04T21:17:19Z

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