From: Masami Hiramatsu <mhiramat@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
lkml <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Mike Galbraith <efault@gmx.de>, Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Christoph Hellwig <hch@infradead.org>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Jim Keniston <jkenisto@us.ibm.com>,
"Frank Ch. Eigler" <fche@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
systemtap <systemtap@sources.redhat.com>,
DLE <dle-develop@lists.sourceforge.net>
Subject: Re: [PATCH -tip tracing/kprobes 0/9] tracing/kprobes, perf: perf probe and kprobe-tracer bugfixes
Date: Mon, 19 Oct 2009 14:56:21 -0400 [thread overview]
Message-ID: <4ADCB655.2020101@redhat.com> (raw)
In-Reply-To: <20091019075103.GF17960@elte.hu>
Ingo Molnar wrote:
>>> Here are a few syntax suggestions
>>>
>>> The simpest probe syntax should be to add a probe to a single
>>> function name:
>>>
>>> perf probe +schedule
>>>
>>> _nothing else_.
>>>
>>> To remove it, the user should just do something like:
>>>
>>> perf probe -schedule
>>>
>>> (to be symmetric 'perf probe +schedule' should work as well)
>>
>> I think '-<symbol>' syntax doesn't work good with other command-line
>> options and multiple definitions. (However, it will be good for
>> input-from-file syntax. :-))
>
> dash can be used too - perf has the options library from Git and there's
> a wide spectrum of option parsing available, via
> tools/perf/util/parse-options.h.
>
> But yes, it complicates things a bit.
Yeah, what I'm concerning about is that user will confuse when deleting
probe points which starts with other option, like 'k'.
(-kmalloc can mean -k malloc too)
>> 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
>
> There's a few well-known command line idioms to add/remove stuff, but -D
> / -U is not one of them i'm afraid =B-)
>
> The following ones might work too:
>
> perf probe +schedule
> perf probe -schedule
>
> perf probe add schedule
> perf probe del schedule
>
> perf probe --add schedule
> perf probe --del schedule
>
> [ Plain 'add/del' has a minor complication as we could have a similar
> symbol defined. ]
>
> + / - is certainly the simplest.
>
> --add/--del works like routes do, so that's intuitive as well. As long
> as we have the simple default to add a new probe at a function, without
> any extra options we can do this too initially.
How about the following syntax?
<adding>
perf probe schedule
perf probe --add schedule
<deleting>
perf probe --del schedule
perf probe --del all /* delete all probepoints */
So, this doesn't symmetric, but provides simple way to add a probe.
>>> 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
>
> would be a rather intuitive shortcut for '15 lines into the schedule()
> function' - and it might even be a largely cross-kernel-version
> compatible way of specifying probe points.
I agreed with the cross-kernel-version issue. I'd rather like
perf probe symbol:relative-line
and
perf probe file:absolute-line
since it will be familiar for GDB users.
And I'd like to preserve
perf probe symbol+offs-byte
for assembly users who might want to trace assembly code with
objdump.
> 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.
Hmm, maybe, it's possible. I should investigate dwarf more...
Thank you!
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
next prev parent reply other threads:[~2009-10-19 18:55 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-17 0:07 [PATCH -tip tracing/kprobes 0/9] tracing/kprobes, perf: perf probe and kprobe-tracer bugfixes Masami Hiramatsu
2009-10-17 0:07 ` [PATCH -tip tracing/kprobes 1/9] tracing/kprobes: Update kprobe-tracer selftest against new syntax Masami Hiramatsu
2009-10-17 10:04 ` [tip:perf/probes] " tip-bot for Masami Hiramatsu
2009-10-17 0:07 ` [PATCH -tip tracing/kprobes 2/9] tracing/kprobes: Add failure messages for debugging Masami Hiramatsu
2009-10-17 10:05 ` [tip:perf/probes] " tip-bot for Masami Hiramatsu
2009-10-17 0:07 ` [PATCH -tip tracing/kprobes 3/9] x86: Add MMX/SSE opcode groups to opcode map Masami Hiramatsu
2009-10-17 10:05 ` [tip:perf/probes] " tip-bot for Masami Hiramatsu
2009-10-17 0:07 ` [PATCH -tip tracing/kprobes 4/9] x86: Add AMD prefetch and 3DNow! opcodes " Masami Hiramatsu
2009-10-17 10:05 ` [tip:perf/probes] " tip-bot for Masami Hiramatsu
2009-10-17 0:07 ` [PATCH -tip tracing/kprobes 5/9] perf: Check libdwarf APIs for perf probe Masami Hiramatsu
2009-10-17 10:05 ` [tip:perf/probes] " tip-bot for Masami Hiramatsu
2009-10-17 0:08 ` [PATCH -tip tracing/kprobes 6/9] perf: Use die() for error cases in perf-probe Masami Hiramatsu
2009-10-17 10:06 ` [tip:perf/probes] " tip-bot for Masami Hiramatsu
2009-10-17 0:08 ` [PATCH -tip tracing/kprobes 7/9] perf: Use eprintf() for debug messages " Masami Hiramatsu
2009-10-17 10:06 ` [tip:perf/probes] " tip-bot for Masami Hiramatsu
2009-10-17 0:08 ` [PATCH -tip tracing/kprobes 8/9] perf: Add DIE_IF() macro for error checking Masami Hiramatsu
2009-10-17 10:06 ` [tip:perf/probes] " tip-bot for Masami Hiramatsu
2009-10-17 0:08 ` [PATCH -tip tracing/kprobes 9/9] perf: Add perf-probe document Masami Hiramatsu
2009-10-17 10:06 ` [tip:perf/probes] " tip-bot for Masami Hiramatsu
2009-10-17 8:02 ` [PATCH -tip tracing/kprobes 0/9] tracing/kprobes, perf: perf probe and kprobe-tracer bugfixes Ingo Molnar
2009-10-17 10:34 ` Ingo Molnar
2009-10-17 10:37 ` Ingo Molnar
2009-10-18 6:01 ` Masami Hiramatsu
2009-10-19 7:51 ` Ingo Molnar
2009-10-19 11:00 ` Frederic Weisbecker
2009-10-19 11:21 ` Ingo Molnar
2009-10-19 19:32 ` Frederic Weisbecker
2009-10-20 6:43 ` Ingo Molnar
2009-10-20 17:51 ` Frederic Weisbecker
2009-10-19 19:51 ` Masami Hiramatsu
2009-10-19 22:54 ` Masami Hiramatsu
2009-10-20 6:51 ` Ingo Molnar
2009-10-21 0:05 ` Masami Hiramatsu
2009-10-20 6:50 ` Ingo Molnar
2009-10-20 14:38 ` Masami Hiramatsu
2009-10-19 16:18 ` Arnaldo Carvalho de Melo
2009-10-20 17:45 ` Frederic Weisbecker
2009-10-19 18:56 ` Masami Hiramatsu [this message]
2009-10-20 6:54 ` Ingo Molnar
2009-10-20 14:27 ` Masami Hiramatsu
2009-10-19 23:10 ` Ashwin Chaugule
2009-10-20 0:30 ` Masami Hiramatsu
2009-10-20 1:59 ` Ashwin Chaugule
2009-10-20 6:55 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ADCB655.2020101@redhat.com \
--to=mhiramat@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=ananth@in.ibm.com \
--cc=dle-develop@lists.sourceforge.net \
--cc=efault@gmx.de \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
--cc=systemtap@sources.redhat.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.