Frederic Weisbecker wrote: > On Thu, Aug 13, 2009 at 04:59:19PM -0400, Masami Hiramatsu wrote: >> This program converts probe point in C expression to kprobe event >> format for kprobe-based event tracer. This helps to define kprobes >> events by C source line number or function name, and local variable >> name. Currently, this supports only x86(32/64) kernels. >> >> >> Compile >> -------- >> Before compilation, please install libelf and libdwarf development >> packages. >> (e.g. elfutils-libelf-devel and libdwarf-devel on Fedora) > > > This may probably need a specific libdwarf version? > > c2kpe.c: In function ‘die_get_entrypc’: > c2kpe.c:422: erreur: ‘Dwarf_Ranges’ undeclared (first use in this function) > c2kpe.c:422: erreur: (Each undeclared identifier is reported only once > c2kpe.c:422: erreur: for each function it appears in.) > c2kpe.c:422: erreur: ‘ranges’ undeclared (first use in this function) > c2kpe.c:447: attention : implicit declaration of function ‘dwarf_get_ranges’ > c2kpe.c:451: attention : implicit declaration of function ‘dwarf_ranges_dealloc’ Aah, sure, it should be compiled with libdwarf newer than 20090324. You can find it in http://reality.sgiweb.org/davea/dwarf.html BTW, libdwarf and libdw (which is the yet another implementation of dwarf library) are still under development, e.g. libdwarf doesn't support gcc-4.4.1(very new) and only the latest libdw(0.142) can support it. So, perhaps I might better port it on libdw, even that is less documented...:( >> TODO >> ---- >> - Fix bugs. >> - Support multiple probepoints from stdin. >> - Better kmodule support. >> - Use elfutils-libdw? >> - Merge into trace-cmd or perf-tools? > > > Yeah definetly, that would be a veeery interesting thing to have. > I've played with kprobe ftrace to debug something this evening. > > It's very cool to be able to put dynamic tracepoints in desired places. > > But... > I firstly needed to put random trace_printk() in some places to > observe some variables values. And then I thought about the kprobes > tracer and realized I could do that without the need of rebuilding > my kernel. Then I've played with it and indeed it works well and > it's useful, but at the cost of reading objdump based assembly > code to find the places where I could find my variables values. > And after two or three probes in such conditions, I've become > tired of that, then I wanted to try this tool. > > > While I cannot yet because of this build error, I can imagine > the power of such facility from perf. > > We could have a perf probe that creates a kprobe event in debugfs > (default enable = 0) and which then rely on perf record for the actual > recording. > > Then we could analyse it through perf trace. > Let's imagine a simple example: > > int foo(int arg1, int arg2) > { > int var1; > > var1 = arg1; > var1 *= arg2; > var1 -= arg1; > > ------> insert a probe here (file bar.c : line 60) > > var1 ^= ... > > return var1; > } > > ./perf kprobe --file bar.c:60 --action "arg1=%d","arg2=%d","var1=%d" -- ls -R / I recommend it should be separated from record, like below: # set new event ./perf kprobe --add kprobe:event1 --file bar.c:60 --action "arg1=%d","arg2=%d","var1=%d" # record new event ./perf record -e kprobe:event1 -a -R -- ls -R / This will allow us to focus on one thing -- convert C to kprobe-tracer. And also, it can be listed as like as tracepoint events. > ./perf trace > arg1=1 arg2=1 var1=0 > arg1=2 arg2=2 var1=2 > etc.. > > You may want to sort by field: > > ./perf trace -s arg1 --order desc > arg1=1 > | > ------- arg2=1 var=1 > | > ------- arg2=2 var=1 > > arg1=2 > | > ------- arg2=1 var=0 > | > ------- [...] > > ./perf trace -s arg1,arg2 --order asc > arg1=1 > | > ------- arg2=1 > | > --------- var1=0 > | > --------- var1=.... > arg2=... > | > > Ok the latter is a bad example because var1 will always have only one > value for a given arg1 and arg2. But I guess you see the point. > > You won't have to care about the perf trace part, it's already > implemented and I'll soon handle the sorting part. > > All we need is the perf kprobes that translate a C level > probing expression to a /debug/tracing/kprobe_events compliant > thing. And then just call perf record with the new created > event as an argument. Indeed, that's what I imagine. Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division e-mail: mhiramat@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
