On Fri, 15 Sep 2006 13:38:58 +0100
Alan Cox <[email protected]> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
