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: Wed, 04 Dec 2013 16:39:34 +0900 [thread overview]
Message-ID: <529EDC36.5050108@hitachi.com> (raw)
In-Reply-To: <529E8903.7060907@gmail.com>
(2013/12/04 10:44), David Ahern wrote:
> On 12/3/13, 6:22 PM, Masami Hiramatsu wrote:
>
>>> I figured out what you meant by uprobe_events interface yesterday. If I
>>> have to go to that interface for even 1 function I would do it for all
>>> -- from a user perspective it is just simpler to have 1 command to setup
>>> probes. I would prefer that 1 command be perf-probe.
>>
>> Yeah, but in that case, why you don't ask us adding sym->binding == STB_LOCAL
>> in filter_available_functions? :)
>
> I did in a separate email -- you said because there can be multiple
> local functions with the same name.
Yeah, and this still seems to be a kind of workaround for me. The best way
to make you requirement enable is to support dwarf for userspace tracing.
OK I'll try it.
> But local functions is not the only
> use case I need.
What would you like to do with perf probe? Direct address accessing for
userspace is not a good way to do, because userspace is relocatable...
> For now I will carry the patch locally. At this point I am 20 patches
> deep and have probably another 20 to go. What's one more. I'll come back
> to this when I have more time.
Would you have any public git repository for that? And could you share
us what would you like to do before sending patch? We can help you to
tell the best way.
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-04 7:39 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
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 [this message]
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=529EDC36.5050108@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