From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frederic Weisbecker Subject: Re: [TOOL] c2kpe: C expression to kprobe event format converter Date: Tue, 1 Sep 2009 00:14:30 +0200 Message-ID: <20090831221428.GE6048@nowhere> References: <20090813203403.31965.20973.stgit@localhost.localdomain> <4A847EA7.20307@redhat.com> <20090830195041.GA6189@nowhere> <4A9B4E2A.1070201@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Ingo Molnar , Steven Rostedt , lkml , Ananth N Mavinakayanahalli , Avi Kivity , Andi Kleen , Christoph Hellwig , "Frank Ch. Eigler" , "H. Peter Anvin" , Jason Baron , Jim Keniston , "K.Prasad" , Lai Jiangshan , Li Zefan , =?utf-8?B?UHJ6ZW15c8WCYXdQYXdlxYJjenlr?= , Roland McGrath , Sam Ravnborg , Srikar Dronamraju , Tom Zanussi , Vegard Nossum , systemtap , kvm , DLE To: Masami Hiramatsu Return-path: Received: from mail-ew0-f206.google.com ([209.85.219.206]:52170 "EHLO mail-ew0-f206.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750992AbZHaWOd (ORCPT ); Mon, 31 Aug 2009 18:14:33 -0400 Content-Disposition: inline In-Reply-To: <4A9B4E2A.1070201@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 variabl= e > >> 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) > >=20 > >=20 > > This may probably need a specific libdwarf version? > >=20 > > c2kpe.c: In function =E2=80=98die_get_entrypc=E2=80=99: > > c2kpe.c:422: erreur: =E2=80=98Dwarf_Ranges=E2=80=99 undeclared (fir= st use in this function) > > c2kpe.c:422: erreur: (Each undeclared identifier is reported only o= nce > > c2kpe.c:422: erreur: for each function it appears in.) > > c2kpe.c:422: erreur: =E2=80=98ranges=E2=80=99 undeclared (first use= in this function) > > c2kpe.c:447: attention : implicit declaration of function =E2=80=98= dwarf_get_ranges=E2=80=99 > > c2kpe.c:451: attention : implicit declaration of function =E2=80=98= dwarf_ranges_dealloc=E2=80=99 >=20 > 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. =20 > 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? > >=20 > >=20 > > Yeah definetly, that would be a veeery interesting thing to have. > > I've played with kprobe ftrace to debug something this evening. > >=20 > > It's very cool to be able to put dynamic tracepoints in desired pla= ces. > >=20 > > 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. > >=20 > >=20 > > While I cannot yet because of this build error, I can imagine > > the power of such facility from perf. > >=20 > > We could have a perf probe that creates a kprobe event in debugfs > > (default enable =3D 0) and which then rely on perf record for the a= ctual > > recording. > >=20 > > Then we could analyse it through perf trace. > > Let's imagine a simple example: > >=20 > > int foo(int arg1, int arg2) > > { > > int var1; > >=20 > > var1 =3D arg1; > > var1 *=3D arg2; > > var1 -=3D arg1; > >=20 > > ------> insert a probe here (file bar.c : line 60) > >=20 > > var1 ^=3D ... > >=20 > > return var1; > > } > >=20 > > ./perf kprobe --file bar.c:60 --action "arg1=3D%d","arg2=3D%d","var= 1=3D%d" -- ls -R / >=20 > I recommend it should be separated from record, like below: >=20 > # set new event > ./perf kprobe --add kprobe:event1 --file bar.c:60 --action "arg1=3D%d= ","arg2=3D%d","var1=3D%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.=20 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-trace= r. > And also, it can be listed as like as tracepoint events. Yeah. > > ./perf trace > > arg1=3D1 arg2=3D1 var1=3D0 > > arg1=3D2 arg2=3D2 var1=3D2 > > etc.. > >=20 > > You may want to sort by field: > >=20 > > ./perf trace -s arg1 --order desc > > arg1=3D1 > > | > > ------- arg2=3D1 var=3D1 > > | > > ------- arg2=3D2 var=3D1 > >=20 > > arg1=3D2 > > | > > ------- arg2=3D1 var=3D0 > > | > > ------- [...] > >=20 > > ./perf trace -s arg1,arg2 --order asc > > arg1=3D1 > > | > > ------- arg2=3D1 > > | > > --------- var1=3D0 > > | > > --------- var1=3D.... > > arg2=3D... > > | > >=20 > > Ok the latter is a bad example because var1 will always have only o= ne > > value for a given arg1 and arg2. But I guess you see the point. > >=20 > > You won't have to care about the perf trace part, it's already > > implemented and I'll soon handle the sorting part. > >=20 > > 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. >=20 > Indeed, that's what I imagine. Cool, thanks! > Thank you, >=20 > --=20 > Masami Hiramatsu >=20 > Software Engineer > Hitachi Computer Products (America), Inc. > Software Solutions Division >=20 > e-mail: mhiramat@redhat.com >=20