From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Jiri Olsa <jolsa@redhat.com>, Ingo Molnar <mingo@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
David Ahern <dsahern@gmail.com>,
linux-kernel@vger.kernel.org, Martin Cermak <mcermak@redhat.com>
Subject: Re: Re: [RFC] perf probe: -x option position issue
Date: Wed, 01 Apr 2015 17:37:10 +0900 [thread overview]
Message-ID: <551BAE36.3030301@hitachi.com> (raw)
In-Reply-To: <20150331133348.GF9438@kernel.org>
(2015/03/31 22:33), Arnaldo Carvalho de Melo wrote:
> Em Tue, Mar 31, 2015 at 05:04:18PM +0900, Masami Hiramatsu escreveu:
>> (2015/03/31 4:48), Arnaldo Carvalho de Melo wrote:
>>> No, I can't, I'd say we should support that, i.e. inserting multiple
>>> probes per command line, for different DSOs, etc. I.e. the above would
>>> be equivalent to these two calls:
>
>>> [root@ssdandy acme]# perf probe -a icmp_rcv
>>> Added new event:
>>> probe:icmp_rcv (on icmp_rcv)
>
>>> You can now use it in all perf tools, such as:
>
>>> perf record -e probe:icmp_rcv -aR sleep 1
>
>>> [root@ssdandy acme]# perf probe -x ./ex -a main
>>> Added new event:
>>> probe_ex:main (on main in /home/acme/ex)
>
>>> You can now use it in all perf tools, such as:
>
>>> perf record -e probe_ex:main -aR sleep 1
>
>>> [root@ssdandy acme]#
>
>> OK, finally we should support that.
>
>>> But it isn't like that, so, yes, what you report is a bug, both for your
>>> expectation (that I think is that it should put a uprobes with both your
>>> examples) and for mine (that it would add the first to the kernel, and
>>> the second to the selected DSO via -x).
>
>> Yes, both are bugs. I'll fix that.
>
>> BTW, let me check that the below behaviors are OK for you.
>
>> perf probe -x BIN -a XXX
>> -> setup XXX on BIN
>
> Ok
>
>> perf probe -a XXX -x BIN
>> -> setup XXX on BIN
>> perf probe -a XXX -x BIN -a YYY
>> -> setup XXX on kernel and YYY on BIN
>
> The two above are inconsistent, I think, first one, for me, doesn't make
> sense, i.e. it says: Add XXX to the selected DSO, which, as none was
> specified at that point, should be the kernel, right?
OK.
>
> I.e. if we do:
>
>> perf probe -a XXX
>
> Without that extra -x that is coming _after_ the command to add a probe
> to XXX (-a XXX), what is that the tool should do (does from day 1, when
> 'probe' was first introduced in tools/perf/):
>
> Add a probe to XXX _in the kernel_, i.e. not specifying a DSO means: its
> for the kernel.
>
> So, for me:
>
>> perf probe -a XXX -x BIN
>> -> setup XXX on BIN
>
> Is invalid (or inocuous if what one wants is to add a probe for XXX on
> the BIN dso), because it doesn't make sense _if you want to support
> adding multiple probes for different DSOs on the same command line_,
> because it would mean:
>
> Add a probe to XXX _in the kernel_, then select BIN as the DSO for
> which probes will be then specified, but in this example, none are
> specified after that "-x BIN", so, I think that:
>
> perf probe -a XXX -x BIN
>
> and:
>
> perf probe -a XXX
>
> Mean the same thing, i.e. add a probe for XXX in the kernel.
OK, so if we have -x BIN after -a, it should have an error, since
that may be not what the user intend.
>> perf probe -x BIN -a XXX -x BIN2 -a YYY
>> -> setup XXX on BIN and YYY on BIN2
>
> Ok.
>
> Also, more generically, I think that:
>
> perf probe -a AAA -a BBB -a CCC -a DDD -x /lib64/libc-2.17.so -a malloc -a free \
> -x /usr/lib64/libthread_db-1.0.so -a td_lookup -a td_thr_event_enable
>
> Should add kprobes for AAA, BBB, CCC and DDD in the kernel, uprobes for
> malloc and free on libc and uprobes for td_lookup and
> td_thr_event_enable on libthread_db.
Yes, that is what I'll do on perf probe. All the probes after -x XXX are
defined on XXX binary (or module).
>
> Making it even more compact would be a bonus:
>
> perf probe -a AAA,BBB,CCC,DDD -x /lib64/libc-2.17.so -a malloc,free \
> -x /usr/lib64/libthread_db-1.0.so -a td_lookup,td_thr_event_enable
>
> :-)
Sorry, this does not fit to current syntax of probe definition, since
we may have some arguments on each event...
Thank you,
--
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-04-01 8:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 17:46 [RFC] perf probe: -x option position issue Jiri Olsa
2015-03-30 19:48 ` Arnaldo Carvalho de Melo
2015-03-31 8:04 ` Masami Hiramatsu
2015-03-31 13:33 ` Arnaldo Carvalho de Melo
2015-04-01 8:37 ` Masami Hiramatsu [this message]
2015-04-01 10:25 ` [PATCH perf/core 1/2] perf-probe: Support multiple probes on different binaries Masami Hiramatsu
2015-04-11 6:37 ` [tip:perf/core] perf probe: " tip-bot for Masami Hiramatsu
2015-04-01 10:25 ` [PATCH perf/core 2/2] perf-probe: Check the orphaned -x option Masami Hiramatsu
2015-04-01 11:11 ` Jiri Olsa
2015-04-10 6:51 ` Masami Hiramatsu
2015-04-10 13:22 ` Arnaldo Carvalho de Melo
2015-04-11 6:38 ` [tip:perf/core] perf probe: " tip-bot for 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=551BAE36.3030301@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=dsahern@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcermak@redhat.com \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).