Re: Tracepoints functionality for local targets

[Michael Snyder <msnyder at specifix dot com>]

On Wed, 2008-02-27 at 09:08 +0100, Lokesh Gupta wrote:
> Hello,
> 
> Can't we take the following approach to this issue:
> 
> - Treat tracepoints as 'silent' breakpoints such that when the user
> sets tracepoints actually a breakpoint is inserted with a special
> property called as 'trace-silent'
> - During execution, when this breakpoint is hit, the usual GDB flow of
> handling the breakpoint comes into picture, GDB gets control, it
> collects all required data from the current frame ($regs,$args,$locals
> as requested by user for this tracepoint), and then silently continues
> the execution because it can identify it as a special breakpoint with
> the property of 'trace-silent'

This would definitely be one possible implementation.

By the way, the tracepoint framework was designed to be largely
implementation-independent, so that to a large extent it should 
be able to work with any of a number of different implementations.

What you suggest would have the advantage of being pretty 
general (should work with native/remote/sim/whatever), but
it has one big disadvantage -- as soon as gdb becomes involved
with the tracepoint data collection, you lose the advantage of
speed.

Part of the goal of tracepoints is to be as un-intrusive as
possible -- get in and get out without interfering with the
timing of the target system any more than necessary.  If
you're willing to compromise that goal, then you can do
things as you describe.

There's also no reason we can't have multiple tracepoint
implementations in place at the same time, so long as we
have a way of selecting between them.  Eg. turn off the
general-but-slow method if you have available a 
target-specific-but-fast method.