Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Stan Shebs <stan@codesourcery.com>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Dominique Toupin <dominique.toupin@ericsson.com>,
	gdb@sourceware.org,   "Frank Ch. Eigler" <fche@redhat.com>,
	 systemtap@sourceware.org
Subject: Re: Static/dynamic userspace/kernel trace
Date: Tue, 20 Apr 2010 18:06:00 -0000	[thread overview]
Message-ID: <4BCDED2D.4020106@codesourcery.com> (raw)
In-Reply-To: <20100420140046.GB20675@linux.vnet.ibm.com>

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


      reply	other threads:[~2010-04-20 18:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <D58A856745AB5A47B1448181D1A8BBFA01CB20875C@EUSAACMS0701.eamcs.ericsson.se>
2010-04-19 14:14 ` Frank Ch. Eigler
2010-04-19 19:50   ` Dominique Toupin
2010-04-20  7:59     ` Mark Wielaard
2010-04-22 19:46       ` Dominique Toupin
2010-04-20 17:28     ` Frank Ch. Eigler
2010-04-20 14:01   ` Srikar Dronamraju
2010-04-20 18:06     ` Stan Shebs [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BCDED2D.4020106@codesourcery.com \
    --to=stan@codesourcery.com \
    --cc=dominique.toupin@ericsson.com \
    --cc=fche@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox