Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752937AbbDAIhV (ORCPT ); Wed, 1 Apr 2015 04:37:21 -0400 Received: from mail9.hitachi.co.jp ([133.145.228.44]:60912 "EHLO mail9.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750793AbbDAIhQ (ORCPT ); Wed, 1 Apr 2015 04:37:16 -0400 Message-ID: <551BAE36.3030301@hitachi.com> Date: Wed, 01 Apr 2015 17:37:10 +0900 From: Masami Hiramatsu Organization: Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Arnaldo Carvalho de Melo CC: Jiri Olsa , Ingo Molnar , Namhyung Kim , Peter Zijlstra , David Ahern , linux-kernel@vger.kernel.org, Martin Cermak Subject: Re: Re: [RFC] perf probe: -x option position issue References: <20150330174655.GA27546@krava.redhat.com> <20150330194849.GH32560@kernel.org> <551A5502.4070905@hitachi.com> <20150331133348.GF9438@kernel.org> In-Reply-To: <20150331133348.GF9438@kernel.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4166 Lines: 131 (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 -- 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/