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

[Andrew Morton <akpm@osdl.org>]

On Fri, 15 Sep 2006 13:38:58 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> gcc -g produces extensive annotations which are then usably by many
> tools other than gdb.

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.



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.

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.


(*) 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.