Re: Tracepoints functionality for local targets

["Lokesh Gupta" <lokesh dot gupta at gmail dot com>]

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'
- The data which is collected by an enabled tracepoint is stored as a
'snapshot' which is a node in a linked list of all snapshots collected
during program execution. This linked list could be used for the
implementation of the tfind like functions to provide necessary
information to the user.

Regards
Lokesh Gupta

On Tue, Feb 26, 2008 at 7:38 PM, Michael Snyder <msnyder@specifix.com> wrote:
>
> On Tue, 2008-02-26 at 09:27 +0100, Lokesh Gupta wrote:
>  > Hello,
>  >
>  > Is there some work planned for the working of the tracepoints for
>  > local targets? While going through the source code, I realized that
>  > currently this facility is only for remote targets.
>  > In case nothing is planned, can I have some guidance on how to achieve
>  > this. I think that it could be a good enhancement to debug
>  > multi-threaded programs on the local host.
>
>  You could define it as two challenges to be addressed:
>  1) How to instrument the code and collect the data on a
>  native system, and
>  2) the fact that the gdb side is only written to handle
>  the remote target.
>
>  I would certainly love to see a native implementation
>  happen, and it would be fair to say that #2 is my fault,
>  so if somebody were to seriously undertake solving #1,
>  I would undertake to at least help work on #2...
>
>  Michael
>
>
>