Re: Static/dynamic userspace/kernel trace

["Frank Ch. Eigler" <fche at redhat dot com>]

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