From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: He Kuang <hekuang@huawei.com>, Ingo Molnar <mingo@kernel.org>
Cc: a.p.zijlstra@chello.nl, acme@kernel.org, jolsa@kernel.org,
mingo@redhat.com, wangnan0@huawei.com,
linux-kernel@vger.kernel.org
Subject: Re: Re: [PATCH v3 3/3] perf probe: Show better error message when failed to find variable
Date: Mon, 11 May 2015 21:02:47 +0900 [thread overview]
Message-ID: <55509A67.1040704@hitachi.com> (raw)
In-Reply-To: <55508149.8040404@huawei.com>
On 2015/05/11 19:15, He Kuang wrote:
>
>
> On 2015/5/11 17:50, Ingo Molnar wrote:
>> * He Kuang <hekuang@huawei.com> wrote:
>>
>>> Hi, Ingo
>>>
>>> On 2015/5/11 17:30, Ingo Molnar wrote:
>>>> * He Kuang <hekuang@huawei.com> wrote:
>>>>
>>>>> Indicate to check variable location range in error message when we got
>>>>> failed to find the variable.
>>>>>
>>>>> Before this patch:
>>>>>
>>>>> $ perf probe --add 'generic_perform_write+118 bytes'
>>>>> Failed to find the location of bytes at this address.
>>>>> Perhaps, it has been optimized out.
>>>>> Error: Failed to add events.
>>>>>
>>>>> After this patch:
>>>>> $ perf probe --add 'generic_perform_write+118 bytes'
>>>>> Failed to find the location of bytes at this address.
>>>> What does this sentence mean? I thought 'address' means 'location of
>>>> bytes'. So the address identifies the location and obviously we know
>>>> that. So this message wants to say something else.
>>> 'generic_perform_write' is a function name, while 'bytes' is a local
>>> variable in this function. Maybe the variable I chose make you confused.
>>>
>>> This maybe clear:
>>> Failed to find the location of 'bytes' at this address.
>> Yeah, absolutely! This highlights the importance of putting
>> user-supplied symbols into quotes and such.
>>
>> Maybe even write:
>>
>> Failed to find the location of the 'bytes' variable at this address.
OK, He, could you also include this fix?
Thank you,
>>
>> Another question: what does 'generic_perform_write+118' mean here? Why
>> the offset?
>
> This is for setting a kprobe at the location has an offset of 118
> bytes to the entry of the function 'generic_perform_write'.
>
> In the previous patch: https://lkml.org/lkml/2015/5/11/170,
> we show a valid byte offset range of variables in scope, 118 is
> an invalid address which can be read from the result, this offset
> is just for showing the error message.
>
>>
>> Thanks,
>>
>> Ingo
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>
>
--
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2015-05-11 12:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 9:25 [PATCH v3 1/3] perf probe: Remove length limitation for showing available variables He Kuang
2015-05-11 9:25 ` [PATCH v3 2/3] perf probe: Add --range option to show variable location range He Kuang
2015-05-11 12:04 ` Masami Hiramatsu
2015-05-15 6:44 ` [tip:perf/core] perf probe: Add --range option to show a variable 's " tip-bot for He Kuang
2015-05-11 9:25 ` [PATCH v3 3/3] perf probe: Show better error message when failed to find variable He Kuang
2015-05-11 9:30 ` Ingo Molnar
2015-05-11 9:43 ` He Kuang
2015-05-11 9:50 ` Ingo Molnar
2015-05-11 10:15 ` He Kuang
2015-05-11 12:02 ` Masami Hiramatsu [this message]
2015-05-11 13:35 ` Arnaldo Carvalho de Melo
2015-05-11 13:44 ` Arnaldo Carvalho de Melo
2015-05-11 20:31 ` Masami Hiramatsu
2015-05-11 9:31 ` Ingo Molnar
2015-05-15 6:44 ` [tip:perf/core] " tip-bot for He Kuang
2015-05-15 6:43 ` [tip:perf/core] perf probe: Remove length limitation for showing available variables tip-bot for He Kuang
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=55509A67.1040704@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=hekuang@huawei.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=wangnan0@huawei.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.