Re: Tracepoints on gdb/gdbserver

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Sep 30, 2003 at 05:46:54PM +0530, Ramana Radhakrishnan wrote:
> hi all, 
>          This is regarding tracepoints on gdb/ gdbserver. What we are

Great!

> trying to do is to implement tracepoints in gdbserver so that we could
> have some sort of remote tracepointing. We are at a stage right now
> where we are ready to take the plunge into actually implementing
> tracepoints on gdbserver. What we have ready right now are just stubs
> that take care of the protocol communication between gdb/tracepoint.c
> and gdbserver/server.c . The following is a list of ideas / issues that
> we have come up with.
> 
> 
>  * We were thinking of piggybacking the tracepoint support with
> breakpoints in gdbserver , add a flag indicating that it would be a
> tracepoint to reuse the code that the software breakpoint now uses in
> gdbserver. As we see it there is not too much of a difference between
> tracepoints and breakpoints other than the actions performed on a
> {break/trace}point hit. By doing this the tracepoint implementation
> could piggy back on the breakpoint support and this could also give rise
> to per thread tracepoints in a mechanism similar to per thread
> breakpoints. 

That'll work.  I got the impression that tracepoints are designed to be
even lighter-weight than that; you can implement them via an agent
expression -> native assembly conversion.  But this requires runtime
patching and is quite complicated.  Just saving the overhead of the
remote protocol will be useful.

> * Another specification according to the info pages seems to be that
> about the fact that all queries to the stub regarding memory / register
> information should be answered by the stub from the current snapshot of
> a tracepoint.
> 
> * Changes to be made in memory request handler , the handler for the
> m<address>,<numbytes> packet in gdbserver/server.c to take care of
> memory requests of transparent regions.
> 
>  * Agent Expressions Interpreter integration with gdbserver. The
> interpreter to take care of actions to be performed / the actual data to
> be collected for every tracepoint.
> 
>  * Collect Locals issue : with gdb snapshot dated 20030821 we are unable
> to take care of collect $locals and collect $args  .This gives an error
> in gdb "Dont know how to trace local  symbol ". This seems to be the
> error value and it looks like support for the Address Class of a symbol
> (LOC_COMPUTED) is not being taken care of right now. 

That's right.  If someone implements the remainder of tracepoint
support I'll go back to looking at LOC_COMPUTED.

Do you have FSF copyright paperwork on file?  If not, please do so.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer