[lkml]   [2009]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.


    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.



     \ /
      Last update: 2009-10-19 13:03    [W:0.024 / U:0.456 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site