This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Tracepoints on gdb/gdbserver
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: ramana at codito dot com
- Cc: gdb at sources dot redhat dot com, jimb at redhat dot com, ac131313 at redhat dot com
- Date: Tue, 30 Sep 2003 08:50:18 -0400
- Subject: Re: Tracepoints on gdb/gdbserver
- References: <1064924214.3808.157.camel@numenor.codito.co.in>
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