From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: David Ahern <dsahern@gmail.com>
Cc: acme@ghostprotocols.net, linux-kernel@vger.kernel.org,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
Oleg Nesterov <oleg@redhat.com>,
namhyung@kernel.org,
"yrl.pp-manager.tt@hitachi.com" <yrl.pp-manager.tt@hitachi.com>
Subject: Re: [PATCH 2/2] perf probe: Allow user to specify address within executable
Date: Tue, 03 Dec 2013 18:24:37 +0900 [thread overview]
Message-ID: <529DA355.9090408@hitachi.com> (raw)
In-Reply-To: <529CC97A.6000807@gmail.com>
(2013/12/03 2:55), David Ahern wrote:
> On 12/2/13, 7:49 AM, David Ahern wrote:
>> On 12/1/13, 11:15 PM, Masami Hiramatsu wrote:
>>> (2013/12/02 9:07), David Ahern wrote:
>>>> Allow user to specify an address within an executable. This is useful, for
>>>> example, in probing local functions. If the function name begins with 0x
>>>> then try to convert the supplied name to an address. If succuessful then
>>>> treat the function name as the address within the executable to be probed.
>>>
>>> Hmm, IMHO, this kind of functionality is only good for debugging.
>>
>> Why? perf-probe takes the function name, looks up the address in the
>> executable, adds an offset and then pushes that address to the kernel.
>> Why can't I have an option to jump straight to the desired address?
>>
>> A few use cases that come to mind:
>>
>> 1. Allows manual creation of return probes in kernels which do not have
>> that support.
>>
>> 2. probing static functions
>
> D'oh. That is supposed to be local functions, not static functions.
> Right now perf-probe does not allow probes in local functions of an
> executable. Giving a specific address provides a mean to do that.
No, perf probe for kprobe support to probing on local functions even
if it is inlined. The problem currently you encountered is that
perf probe uprobe support is incomplete. It should be enhanced to
support dwarf(debuginfo) to find the functions(even lines) from it.
I don't want to make perf-probe just a wrapper of the ftrace dynamic
event interface, because it doesn't add any "value" for users.
Current uprobe support state is not sufficient for me.
>>> In that case, you should use uprobe_events interface directly.
>>
>> How do I do that within the context of perf?
No way, but here, you can save this script as perf-uprobe and
can use it for that purpose. :)
---
#!/bin/sh
BIN=$1
FUNC=$2
ADDR=`nm $BIN | grep " $FUNC\$" | cut -f1 -d" "`
echo p $BIN:0x$ADDR > /sys/kernel/debug/tracing/uprobe_events
---
>>> I recommend you to try enabing dwarf support in user space.
>>> Perf probe is a user-friendly interface of dynamic events.
>>
>> I do have dwarf support enabled in perf. Are you referring to other
>> components of userspace (like system libraries)?
Ah, right. Unfortunately, perf probe for uprobes does not support
dwarf for user space yet. This should be enabled for completing
the perf probe work...
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2013-12-03 9:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-02 0:07 [PATCH 1/2] perf probe: Improve error message when function not found David Ahern
2013-12-02 0:07 ` [PATCH 2/2] perf probe: Allow user to specify address within executable David Ahern
2013-12-02 5:53 ` Masami Hiramatsu
2013-12-02 6:15 ` Masami Hiramatsu
2013-12-02 14:49 ` David Ahern
2013-12-02 17:55 ` David Ahern
2013-12-03 9:24 ` Masami Hiramatsu [this message]
2013-12-03 15:58 ` David Ahern
2013-12-04 1:22 ` Masami Hiramatsu
2013-12-04 1:44 ` David Ahern
2013-12-04 7:39 ` Masami Hiramatsu
2013-12-08 17:50 ` David Ahern
2013-12-02 5:59 ` [PATCH 1/2] perf probe: Improve error message when function not found Masami Hiramatsu
2013-12-02 14:52 ` David Ahern
2013-12-03 5:12 ` Masami Hiramatsu
2013-12-03 15:15 ` David Ahern
2013-12-04 1:23 ` Masami Hiramatsu
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=529DA355.9090408@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=acme@ghostprotocols.net \
--cc=dsahern@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung@kernel.org \
--cc=oleg@redhat.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=yrl.pp-manager.tt@hitachi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox