RE: Static/dynamic userspace/kernel trace

[Dominique Toupin <dominique.toupin@ericsson.com>]

I agree that GDB could use a better ptrace.

Regarding tracing, for me the main use case is to get the data out of the system very fast and with very low overhead, besides conditional tracing and a few minor things, most of the analysis is done on the host side, either after the fact or in streaming mode. Doing historical analysis on the target or big actions are not an option for me. I guess in the IT industry more cycles are available to do those kinds of analysis directly on the target server.


> -----Original Message-----
> From: Frank Ch. Eigler [mailto:fche@redhat.com] 
> Sent: 19-Apr-10 10:14
> To: Dominique Toupin
> Cc: gdb@sourceware.org; systemtap@sourceware.org
> Subject: Re: Static/dynamic userspace/kernel trace
> 
> Hi -
> 
> On Mon, Apr 19, 2010 at 09:16:04AM -0400, Dominique Toupin 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
> >  - static kernel: kernel static tracepoint/trace event
> >  - dynamic kernel: kprobe
> >
> > and conditional tracing is available for both kernel and user space.
> 
> All right.
> 
> 
> > Tom was saying uprobes/utrace can bring nice improvements 
> for ptrace, 
> > for tracing it was not clear to me or Tom why we need 
> uprobe/utrace or 
> > why systemtap needs it. Do you have a use case where the 
> above tracing 
> > cannot be use and uprobe/utrace is needed instead?
> 
> Recall that systemtap goes beyond just tracing with simple 
> local conditions.  There are dozens of nontrivial systemtap 
> scripts that involve conditions based on history, searching 
> through live data structures, taking actions, making state 
> changes.  The above technologies do not stretch that far, nor 
> are they integrated.
> 
> The main motivating dependence by systemtap on utrace has 
> been due to uprobes.  We shall see to what extent lkml is 
> receptive to a utrace-free-uprobes implementation being 
> worked on now.  If it is merged and usable, this would moot 
> one particular dependence.  But there are other needs: proper 
> process control facility like utrace enables scripted 
> operations such as clean thread suspend/resume or signal 
> generation/suppression.
> 
> And of course utrace in general has ambitions beyond 
> systemtap.  As oft repeated on lkml etc., some sort of 
> process control multiplexing facility is necessary so that a 
> single ptrace-client tool does not monopolize target 
> processes.  That newfangled gdb tracing stuff does not work 
> if someone was already strace'ing the same process.  This is 
> why we prototyped the gdbstub-in-kernel for userspace 
> processes, based on utrace.  It already demonstrated 
> concurrent gdb+strace on the same threads.
> 
> 
> - FChE
>