Re: [TOOL] c2kpe: C expression to kprobe event format converter

[Frederic Weisbecker]

On Mon, Aug 31, 2009 at 12:14:34AM -0400, Masami Hiramatsu wrote:
> 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


Ah ok.

 
> 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...:(



May be let's continue with libdwarf for now and we'll see if support
for libdw is required later.



> >> 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 /


That indeed solves the command line overkill, but that also
breaks a bit the workflow :)

Well, I guess we can start simple in the beginning and follow the above
mockup which is indeed better decoupled. 
And if something more intuitive comes in mind later, then we can still
change it.


> 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.


Yeah.


> > ./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.



Cool, thanks!




> 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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/