Re: Using gdb as a trace agent

[Jim Blandy <jimb@redhat.com>]

"Eli Zaretskii" <eliz@gnu.org> writes:

> > Date: Mon, 17 May 2004 18:47:51 +0200
> > From: Alexandre Courbot <Alexandre.Courbot@lifl.fr>
> > 
> > The ideal for me would be to be able to use tracepoints in both cases 
> > (i.e. remote and local). What would prevent a local support for tracepoints?
> 
> Nothing, except the fact that the code to do that has not been
> written yet.
> 
> If you fill that void, you will have my eternal gratitude.
> 
> > no chance to get tracepoints to work locally? That would turn GDB
> > into a great analysis tool.
> 
> This was discussed in the past, and everybody agreed it would be
> great.  Now all we need is someone to step forward and code that.

Yep.  Here's why it's only been implemented remotely:

On a typical remote embedded system communicating with GDB via a stub,
the stub is installed as a trap handler: when the debuggee hits a
breakpoint, the processor simply transfers control to the stub.  The
stub then chats with GDB for as long as is necessary, and when it
receives a 'continue' packet, it returns from the trap handler.

This means that it's pretty easy to add tracepoints in a low-overhead
way.  The stub just looks up the address of the instruction at which
the trap occurred in a table of tracepoints; if it finds a tracepoint
at that address, it collects the associated data, and continues
immediately.

So for native configurations, the challenge is to find a low-overhead
way to handle those traps.  For example, one could add tracepoint
support to gdbserver, but then you'd have one process collecting data
from another process via ptrace or some other system call, and it
wouldn't be very lightweight.