lkml.org 
[lkml]   [2009]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -tip tracing/kprobes 0/9] tracing/kprobes, perf: perf probe and kprobe-tracer bugfixes
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.



\
 
 \ /
  Last update: 2009-10-19 13:03    [W:0.164 / U:0.572 seconds]
©2003-2014 Jasper Spaans. Advertise on this site