Re: Tracepoint enhancements

[Vladimir Prus <vladimir@codesourcery.com>]

Michael Snyder wrote:

>> One possible change to consider is to merge tracepoint setting into
>> breakpoint setting. Among other benefits would be a single numbering
>> scheme for breakpoints and tracepoints, plus we will be able to share
>> some machinery and make things more consistent.
> 
> Just my personal opinion, I would find that confusing.
> 
> It seems useful to maintain a fairly sharp distinction
> between breakpoints and tracepoints, since their behavior
> is entirely different from both the implementation and the
> user's point of view.
> 
> But I would not plan to make a fuss about it...

I think breakpoints and tracepoints have very lots of common. 

First of all, the logic of resolving location specification to addresses
is, conceptually the same. Right now, breakpoints in constructors and
template functions work. Tracepoints don't seem to, because the fail
to use the multi-location breakpoint mechanisms. Tracepoints don't have
conditions -- which is something we want to fix -- and handling of condition
is a bit tricky too. Breakpoints in shared libraries work just fine --
and tracepoints should work too -- but they don't use pending breakpoints
mechanisms.

On the interface (MI) level breakpoints and tracepoints are essentially
the same. Breakpoints allow user, or frontend, to do something at specific
points of program. That something very well can be printing variables. In
fact, KDevelop does have "tracing" functionality for breakpoints -- where
on breakpoint hit, selected variables are printed and execution resumes.
Tracepoints are exactly the same, except that:

        - they are more efficient
        - they don't cause frontend to be involved, because to be efficient,
        they are entirely stub-side

So it makes perfect sense to treat tracepoints as specially-optimized versions
of breakpoints. In order for breakpoint to be optimized like this, the list
of commands for that breakpoints should only use a limited set of commands,
and end with 'continue'

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

- Volodya