Tracepoints on gdb/gdbserver

Tracepoints on gdb/gdbserver

[Ramana Radhakrishnan]

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

Re: Tracepoints on gdb/gdbserver

[Daniel Jacobowitz]

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

Re: Tracepoints on gdb/gdbserver

[Ramana Radhakrishnan]

hi,

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

We are working on the paperwork. I am yet to receive the copyright form
in the mail . Its due in sometime this week. Would the copyright form be
necessary before all patches into gdb / gdbserver would be accepted ?

cheers
Ramana

Re: Tracepoints on gdb/gdbserver

[Ramana Radhakrishnan]

On Wed, 2003-10-01 at 04:12, Jim Blandy wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> > 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.
> 
> Yes.  The original implementation used a bytecode interpreter (which
> is really pretty fast), but it was an embedded board with no OS, and
> the interpreter ran in the same address space as the program being
> debugged, so those memory references were just load instructions, and
> the trace opcodes were just memcpy calls.
> 
> If you implement tracepoints in gdbserver, then those are going to
> become ptrace calls, which are going to be a lot slower.  It might
> still be fast enough for your purposes --- but I just want to point
> out that it's not the same arrangement we used in the original
> application.

 I agree that it would be slow but as Daniel points out, compared the
overhead of the remote protocol, it would still be useful.

regards
Ramana

 

Tracepoints with shared lib. support.

[Ramana Radhakrishnan]

hi all, 

 Another query i had was regarding tracepoints on shared library
symbols. That would also have to be handled in a manner similar to the
way in which the breakpoints for shared libraries have been implemented.
I wonder if we need internal breakpoints on the shared library event
handling which would then take care of mapping the addresses to the
actual addresses because with the current status of tracepoints the
addresses do not get mapped to the actual addresses. So if we had a
tracepoint on a function in a shared library would we then not be
increasing the number of halts in the actual execution of the program. 


regards
Ramana

Re: Tracepoints with shared lib. support.

[Daniel Jacobowitz]

On Wed, Oct 01, 2003 at 04:30:23PM +0530, Ramana Radhakrishnan wrote:
> hi all, 
> 
>  Another query i had was regarding tracepoints on shared library
> symbols. That would also have to be handled in a manner similar to the
> way in which the breakpoints for shared libraries have been implemented.
> I wonder if we need internal breakpoints on the shared library event
> handling which would then take care of mapping the addresses to the
> actual addresses because with the current status of tracepoints the
> addresses do not get mapped to the actual addresses. So if we had a
> tracepoint on a function in a shared library would we then not be
> increasing the number of halts in the actual execution of the program. 

Well, tracepoints haven't been made to work with shared libraries yet,
that's true.  But it should be possible to enable/disable/move them at
the same time as breakpoints.  There are always stops when loading a
shared library, and you'll have a whole lot of work cut out for you if
you want to change that.  So the tracepoints don't increase the number
of halts.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer