This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Static/dynamic userspace/kernel trace


Srikar Dronamraju wrote:
I had a chat with Tom at the collaboration summit on tracing, he was
suggesting I send you a mail on a recent GDB improvement.  You might
not be aware that user space dynamic tracepoint are now available in
GDB, in process tracing if a few byte space is available to put a
jump, if that space is not available then a trap between gdbserver
and the process. With this addition all aspects of tracing seem to
be covered:

- static user space: LTTng UST
- dynamic user space: GDB dynamic tracepoint

I did go thro
http://sources.redhat.com/gdb/current/onlinedocs/gdb.html#Set-Tracepoints
but it says "The tracepoint facility is currently available only for remote targets.
See Targets. In addition, your remote target must know how to collect
trace data. This functionality is implemented in the remote stub;
however, none of the stubs distributed with gdb support tracepoints as
of this writing. "

This is now only accurate in a pedantic sense, since gdbserver does have tracepoint support. The example stubs distributed with GDB have become so old and crufty that they offer very little useful guidance about writing a stub, and are probably actively misleading people; I'm half-inclined to propose their removal.


and

"Some targets may support fast tracepoints, which are inserted in a
different way (such as with a jump instead of a trap), that is faster
but possibly restricted in where they may be installed. "

So it possible to use GDB dynamic tracepoints on regular programs
without using remote protocol? If not do you plans to implement this for
non-remote targets?

No, the gdbserver-based implementation we have at the moment still assumes that the agent is speaking remote protocol back to GDB. However, the not-yet-contributed fast tracepoint library could be tied into a native debugging arrangement, should someone be interested in taking that up.


I am ignorant on how gdb dynamic tracepoints was implemented to comment
on how gdb could further use uprobes/utrace. Can you please point me to
some documentation on the same.

There's not a good general description; gdb/doc/agentexpr.texi has some material on how the agent expressions fit into the bigger tracing picture, but it's also in reference to the EMC target that hasn't been used in years. Now that our first generation of tracepoint revival is done, it would be good to go through the docs and update them.


To respond to the larger point, it's worthwhile for us to get some experience with the different systems, and start thinking about how they can usefully interoperate. Anybody interested in tracing should at least fire up a GDB+GDBserver combo using current sources, and try a trace experiment or two using the manual as guide, just to see how it works in practice. Maybe there's not enough functionality overlap to do anything, but even if that's the case, we can then make a little writeup sending users to the right tracing technology for specific types of problems.

Stan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]