Re: Tracepoints functionality for local targets

[Nicholas Mc Guire <hofrat at hofr dot at>]

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

that is what the current implementation actually does except that we put
the tracepoint into a seperate list of breakpoint instead of changing the
description of the currently in use breakpoints. Basically this was done
this way because working your way through the path of the breakpoint code
atleast in gdbserver was a complete mess.

> - 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 main difference is that you need to add gdb bytecode to the picture
because variables or expressions can't directly be resolved as at time of
defining the variable you don't actually have access to the target - that
is taken care by translating expressions to bytecode and sending the
bytecode to the target that then executes it on hitting a tracepoint and
stores the result only.

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

thats just what the current implementation does - see tp.c and list.c in
the tracpoint code.

hofrat