Re: [PATCH -tip tracing/kprobes 0/9] tracing/kprobes, perf: perf probe and kprobe-tracer bugfixes

[Frederic Weisbecker <fweisbec at gmail dot com>]

On Mon, Oct 19, 2009 at 09:51:03AM +0200, Ingo Molnar wrote:
> > So, what would you think about using -D (def) and -U (undef) ?
> 
> The simpest case should be no extra character at all:
> 
>   perf probe schedule


Yeah, I really prefer that too.


 
> > > All the other extensions and possibilities - arguments, variables, 
> > > source code lines, etc. should be natural and intuitive extensions 
> > > of this basic, minimal syntax.
> > 
> > Don't you like current space(' ') separated arguments? :-) I mean, 
> > what is 'natural' syntax in your opinion?
> 
> Yeah, space separated arguments are nice too. The question is how to 
> specify a more precise coordinate for the bit we want to probe - and how 
> to specify the information we want to extract. Something like:
> 
>   perf schedule+15


I personally don't imagine common easy usecases that imply relative line
offsets but rather absolute lines.

I guess the most immediate usecase is a direct function probe:

	perf probe schedule

Just to know if a function is matched.

If you want more precision, it also means you have you code editor opened
and want to set a precise point. Since you also have the absolute
line directly displayed by your editor, you don't want to calculate the relative
line but rather the absolute one.

Hmm?

Hence I rather imagine the following:

perf probe schedule.c:line

(Unfortunately, schedule:line is shorter but less intuitive
but that could be a shortcut).



> Or this:
> 
>   perf schedule:'switch_count = &prev->nivcsw'
> 
> would insert the probe to the source code that matches that statement 
> pattern. Rarely will people want to insert a probe to an absolutely line 
> number - that's a usage mode for higher level tools. (so we definitely 
> want to support it - but it should not use up valuable spots in our 
> options space.) Same goes for symbol offsets, etc. - humans will rarely 
> use them.



I don't understand your point. If your editor is opened and you have
the source code in front of you, why would you cut'n'paste a line instead
of actually write the line number?



> 
> We also want to have functionality that helps people find probe spots 
> within a function:
> 
>   perf probe --list-lines schedule
> 
> Would list the line numbers and source code of the schedule() function. 
> (similar to how GDB 'list' works) That way someone can have an ad-hoc 
> session of deciding what place to probe, and the line numbers make for 
> an easy ID of the statement to probe.


Agreed!

Thanks.