Re: [PATCH] Fast tracepoints

[Mark Wielaard <mjw at redhat dot com>]

Hi Stan,

On Tue, 2010-01-05 at 16:54 -0800, Stan Shebs wrote:
> Tom Tromey wrote:
> >>>>>> "Stan" == Stan Shebs <stan@codesourcery.com> writes:
> > Stan> This patch adds "fast" tracepoints to GDB.
> >
> > Neat.
> >
> > Stan> Most of the interesting trickery is on the target side - but don't
> > Stan> despair, Pedro has upcoming patches for a free version using gdbserver
> > Stan> and a special library.
> >
> > I wonder whether this could somehow work with systemtap probe points.
> >   
> One of our other projects is to do "static tracepoints" that originate 
> outside GDB, and one of the side effects of the upcoming disconnected 
> tracing patch is that it introduces the idea of keeping the tracepoint 
> definition in the target.  So it seems like a useful convergence to have 
> a tool-independent notion of a probe/tracepoint that can be used in 
> different contexts.

If you have a proposal please do CC systemtap@sourceware.org (I added it
to the CC of this email already). Currently the way systemtap user space
static probe points are handled is by having dtrace compatible source
code markers in the application. We choose that representation in the
source files to maximize reuse of static user space tracepoints across
application/os domains. See also:
http://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps
If we could reuse the definitions in sys/sdt.h as the canonical way of
adding static tracepoints to an application usable from multiple
debuggers/profilers/tracers that would be wonderful.

The markers are currently stored in a special .probes elf section inside
the application or shared library. I don't believe that format is
documented yet (partly because there are still some experiments going on
with adding different representations), but we probably should document
it formally if we would like gdb to reuse it.

Cheers,

Mark