Messages in this thread |  | | Date | Fri, 15 Sep 2006 14:16:18 -0400 | | From | Karim Yaghmour <> | | Subject | Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |