From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Franck Bui-Huu <vagabon.xyz@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
lkml <linux-kernel@vger.kernel.org>,
2nddept-manager@sdl.hitachi.co.jp
Subject: Re: [PATCH] perf-probe: make "perf-probe -L <function>" display the absolute path and absolute line number
Date: Fri, 14 Jan 2011 12:22:37 +0900 [thread overview]
Message-ID: <4D2FC17D.5010203@hitachi.com> (raw)
In-Reply-To: <m34o9c8ual.fsf@gmail.com>
(2011/01/14 4:42), Franck Bui-Huu wrote:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> writes:
>
>> (2011/01/13 19:20), Franck Bui-Huu wrote:
>>> From: Franck Bui-Huu <fbuihuu@gmail.com>
>>>
>>> It should be more usefull to get the full location of the function
>>
>>> (absolute line number + full path) instead of repeating the name of
>>> the function and the start line number given by the command line.
>>>
>>> So we had before:
>>>
>>> $ perf probe -L schedule | head -n3
>>> <schedule:0>
>>> 0 asmlinkage void __sched schedule(void)
>>> 1 {
>>>
>>> and now we get:
>>>
>>> $ perf probe -L schedule | head -n3
>>> </usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64/kernel/sched.c:3813>
>>> 0 asmlinkage void __sched schedule(void)
>>> 1 {
>>
>> Indeed, it could be useful for users to see where the function is...
>>
>> However, I think that should be optional, because the output lines
>> have the relative line numbers from the function, and those numbers
>> are important for users who want to probe a specific line by using
>> function relative line numbers. e.g. "schedule:10"
>>
>> And with that option, I'd suggest to show absolute line numbers on each line.
>>
>> $ perf probe -L schedule:0-1 --by-source
>> </usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64/kernel/sched.c:3813>
>> 3813 asmlinkage void __sched schedule(void)
>> 3814 {
>>
>> Or, just show source file as an additional information.
>>
>> $ perf probe -L schedule:0-1
>> <schedule@/usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64/kernel/sched.c:0>
>> 0 asmlinkage void __sched schedule(void)
>> 1 {
>>
>> I just would like to keep the consistency of the output/input format.
>
> Well, for consistency, I thought that the additional information (given
> inside angle brackets) should always be the same: a full path and an
> absolute line number which clearly identify which source file perf-probe
> is listing.
No, that is NOT an additional information. That indicates from where those
lines are started, and also gives you a hint how you can specify the
actual probe point. For example,
$ perf probe -L schedule:10
<schedule:10>
10 rq = cpu_rq(cpu);
11 rcu_note_context_switch(cpu);
12 prev = rq->curr;
this indicates the lines started from 10th line of schedule(), and
if you want to put a new event on "prev = rq->curr;" line, you
just need to say "perf probe schedule:12"
$ perf probe -L kernel/sched.c:4077
</home/mhiramat/ksrc/linux-2.6-tip/kernel/sched.c:4077>
4077 rq = cpu_rq(cpu);
4078 rcu_note_context_switch(cpu);
4079 prev = rq->curr;
And this also gives you a hint to say (just copy & paste)
"perf probe /home/mhiramat/ksrc/linux-2.6-tip/kernel/sched.c:4079"
Since perf probe also accepts FUNC@SRC:RLN, my suggestion
also keeps that rule.
---
$ perf probe -L schedule:0-1
<schedule@/usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64/kernel/sched.c:0>
0 asmlinkage void __sched schedule(void)
1 {
---
Thank you,
--
Masami HIRAMATSU
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com>
next prev parent reply other threads:[~2011-01-14 3:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-13 10:20 [PATCH] perf-probe: make "perf-probe -L <function>" display the absolute path and absolute line number Franck Bui-Huu
2011-01-13 11:03 ` Masami Hiramatsu
2011-01-13 19:42 ` Franck Bui-Huu
2011-01-14 3:22 ` Masami Hiramatsu [this message]
2011-01-14 9:03 ` Franck Bui-Huu
2011-01-14 10:08 ` Masami Hiramatsu
2011-01-14 10:33 ` Masami Hiramatsu
2011-01-14 19:53 ` Franck Bui-Huu
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=4D2FC17D.5010203@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=2nddept-manager@sdl.hitachi.co.jp \
--cc=acme@ghostprotocols.net \
--cc=linux-kernel@vger.kernel.org \
--cc=vagabon.xyz@gmail.com \
/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.