Tracepoints on gdb/gdbserver

[Ramana Radhakrishnan <ramana.radhakrishnan@codito.com>]

hi all, 
         This is regarding tracepoints on gdb/ gdbserver. What we are
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. 

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




regards
Ramana Radhakrishnan