Messages in this thread | | | Date | Fri, 14 Aug 2009 11:05:45 -0400 | From | Masami Hiramatsu <> | Subject | Re: [RFD] Kprobes/Kretprobes perf support |
| |
Frederic Weisbecker wrote: > Ftrace events are supported by perfcounter currently but Kprobes > dynamic ftrace events are of a different nature: we must create them > before any toggling. > > So a large part is already done through the ftrace events and the fact > that you create one dynamically for each kprobes (we'll just need > a little callback for perf sample submission but that's a small > point). > > The largest work that remains is to port the current powerful interface > to create these k{ret}probes (with requested arguments, etc...) through > ftrace but using perf open syscall. > > And I imagine it won't be trivial. > > Ingo, Peter do you have an idea on how we could do that? > We should be able to choose between a kprobe and kretprobe (these can > be two separate counters). And also one must be able to request the dump > of random desired parameters (or return values in case of kretprobe) > or registers... > > May be we should use the perf attr by passing a __user address to a buffer > that contains all these options? > Once we get that to the kernel, that can be passed to ftrace-kprobe that > can parse it, create the desired trace event and rely on perf to create > a counter for it. > > I guess that won't imply so much adds to Masami's patchset. Most of > the work is on the perf tools (parsing the user request). > > ./perf kprobes -e (func|addr):(c|r):(a1,a2,a3,... | rax,rbx,rcx,...) > ^ ^ > c = call = kprobe > r = return = kretprobe
If it is possible that libdwarf can be linked to the perf tool, I think it might be better to support 'C source line/local variable' style too, because basic dwarf decoding logic has already been done in c2kpe which I posted yesterday :-).
Thank you,
-- Masami Hiramatsu
Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division
e-mail: mhiramat@redhat.com
| |