Messages in this thread | | | Date | Wed, 01 Apr 2015 17:37:10 +0900 | From | Masami Hiramatsu <> | Subject | Re: Re: [RFC] perf probe: -x option position issue |
| |
(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
| |