Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

[Karim Yaghmour <karim@opersys.com>]

Andrew Morton wrote:
> This is something I'm curious about.  AFAICT there are two(*) reasons for
> wanting static tracepoints:
> 
> a) to be able to get at local variables and
> 
> b) as a "marker" somewhere within the body of a function - the
>    expectation here is that identifiying that particular spot in the
>    function would be hard without some marker which moves around as the
>    functions itself is modified over time.
> 
> 
> If a) is true, then isn't this simply a feature request against the
> systemtap infrastructure?  There's no reason per-se why a kprobe point
> cannot access locals, using the dwarf debug info.  It'll be somewhat
> unreliable, because stack slots and registers go out of scope and get
> reused for other things.  But as any gdb user will know, it's still
> useful.

I believe this has been addressed by Frank in his other email, so I'll
skip.

> As for b), if it was _really_ an advantage to be able to identify
> particular places within the body of a function then one could concoct a
> macro which inserts some info into a separate elf section and which adds no
> code at all to actual .text.

Yes, and this specific suggestion has been made a number of times.
Though, then, this is an implementation debate and there are number
of things which could be made available as build-time options. The
emerging consensus in this thread, however, that there is a clear
need for a way for statically marking up important events, and this
point has been emphasized both by those who have maintained
infrastructure based on "static" tracepoints and those maintaining
such infrastructure based on "dynamic" tracepoints.

> Although IMO this is a bit lame - it is quite possible to go into
> SexySystemTapGUI, click on a particular kernel file-n-line and have
> systemtap userspace keep track of that place in the kernel source across
> many kernel versions: all it needs to do is to remember the file+line and a
> snippet of the surrounding text, for readjustment purposes.

Sure, if you're a kernel developer, but as I've explained numberous
times in this thread, there are far more many users of tracing than
kernel developers.

> (*) I don't buy the performance arguments: kprobes are quick, and I'd
> expect that the CPU consumption of the destination of the probe is
> comparable to or higher than the cost of taking the initial trap.

Please see Mathieu's earlier posting of numbers comparing kprobes to
static points. Nevertheless, I do not believe that the use of kprobes
should be pitted against static instrumentation, the two are
orthogonal.

Karim