Re: [PATCH tracing/kprobes v2 0/5] tracing/kprobes, perf: perf probe support take 2

[Frederic Weisbecker <fweisbec@gmail.com>]

On Fri, Oct 02, 2009 at 05:48:34PM -0400, Masami Hiramatsu wrote:
> Hi,
> 
> These patches introduce 'perf probe' command and update kprobe-tracer.
> perf probe command allows you to add new probe points by C line number
> and local variable names.
> 
> This version fixes some bugs, changes subcommand name from kprobe to
> probe and use spaces for separator instead of ',' for visibility (this
> also make it easy to support probe list from stdin).
> 
> Usage
> -----
>  perf probe [<options>] -P 'PROBEDEF' [-P 'PROBEDEF' ...]
> 
>     -k, --vmlinux <file>  vmlinux/module pathname
>     -r, --release <rel>   kernel release
>     -P, --probe <p|r:[GRP/]NAME FUNC[+OFFS][@SRC]|@SRC:LINE [ARG ...]>
>                           probe point definition, where
> 		p:	kprobe probe
> 		r:	kretprobe probe
> 		GRP:	Group name (optional)
> 		NAME:	Event name
> 		FUNC:	Function name
> 		OFFS:	Offset from function entry (in byte)
> 		SRC:	Source code path
> 		LINE:	Line number
> 		ARG:	Probe argument (local variable name or
> 			kprobe-tracer argument format is supported.)
> 
> Examples
> --------
> 1) Add a new kprobe probe on a line of C source code.
> ./perf probe -P 'p:myprobe @fs/read_write.c:285 file buf count'
> Adding new event: p:myprobe vfs_read+57 file=%bx buf=%si count=%ax


Nice! Great thing.

One neat, at a first glance, file=%bx buf=%si look like a format
definition.

How about using file=bx ? Or does that introduce any ambiguities
with kprobes definitions syntax?



> 
> 2) Add a new kretprobe probe on a function return.
> ./perf probe -P 'r:myretprobe vfs_read $rv'
> Adding new event: r:myretprobe vfs_read+0 $rv


The '$' character may perhaps also confuse bash scripts that create
perf probe.



> 3) Check it in the perf list.
> ./perf list
> ...
>   rNNN                                       [raw hardware event descriptor]
> 
>   kprobes:myprobe                            [Tracepoint event]
>   kprobes:myretprobe                         [Tracepoint event]
>   skb:kfree_skb                              [Tracepoint event]
> ...
> 
> 4) Record the event by perf
> ./perf record -f -e kprobes:myprobe:record  -F 1 -a ls
> ...
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.081 MB perf.data (~3540 samples) ]
> 
> 5) Trace the event
> ./perf trace
>             perf-11445 [000] 95862.048894383: myprobe: (c04bbed5) file=dae15e80 buf=b78b2000 count=400
>             perf-11445 [000] 95862.049066533: myprobe: (c04bbed5) file=dae15d80 buf=b78b2000 count=400
>             perf-11445 [000] 95862.049134394: myprobe: (c04bbed5) file=dae15d80 buf=b78b2000 count=400
>             perf-11445 [000] 95862.049171495: myprobe: (c04bbed5) file=dae15a80 buf=b78b2000 count=400
> 
> NOTE
> ----
>  perf still fails to parse format if arguments have special charactors
> (e.g. $rv, +10($sp) etc.) So, tracing myretprobe will fail with this
> version. This will be solved by naming arguments automatically if it
> doesn't have C-language name.
> 
> TODO
> ----
>  - Support sys_perf_counter_open (non-root)


Hmm, we really want it to be only usable by the root
(except if the policy is tuned to allow that, but that's
managed by perf already).


>  - Input from stdin/output to stdout
>  - Non-auto static variable
>  - Fields of data structures (var->field)
>  - Type support
>    - Bit fields
>  - Array (var[N])
>  - Dynamic array indexing (var[var2])
>  - String/dynamic arrays (var:string, var[N..M])
>  - Force Type casting ((type)var)
>  - Non-inline search
>  - libdw, libdwfl
>  - etc.
> 
> Thank you,
> 


Cool, I'm reviewing/testing it and if no rough problem
arise I'll apply it.

Thanks a lot!