From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932605AbdLGRZZ (ORCPT ); Thu, 7 Dec 2017 12:25:25 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:52834 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756310AbdLGRY4 (ORCPT ); Thu, 7 Dec 2017 12:24:56 -0500 Subject: Re: [PATCH v2 2/5] perf-probe: Cut off the version suffix from event name To: Arnaldo Carvalho de Melo , Masami Hiramatsu Cc: bhargavb , linux-kernel@vger.kernel.org, Ravi Bangoria , linux-rt-users@vger.kernel.org, linux-perf-users@vger.kernel.org References: <151263115609.13843.6362262297053841418.stgit@devbox> <151263122864.13843.10998234736675352577.stgit@devbox> <20171207165659.GD3173@kernel.org> From: Paul Clarke Date: Thu, 7 Dec 2017 11:24:47 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171207165659.GD3173@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17120717-0024-0000-0000-0000179E2871 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008167; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000244; SDB=6.00956821; UDB=6.00483708; IPR=6.00736852; BA=6.00005729; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018408; XFM=3.00000015; UTC=2017-12-07 17:24:51 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17120717-0025-0000-0000-00004DCF056E Message-Id: <8f1f552c-c5d0-40e3-14d9-96a4a38b33c6@us.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-07_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712070255 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/07/2017 10:56 AM, Arnaldo Carvalho de Melo wrote: > Em Thu, Dec 07, 2017 at 04:20:28PM +0900, Masami Hiramatsu escreveu: >> Cut off the version suffix (e.g. @GLIBC_2.2.5 etc.) from >> automatic generated event name. This fixes wildcard event >> adding like below case; >> >> ===== >> # perf probe -x /lib64/libc-2.25.so malloc* >> Internal error: "malloc_get_state@GLIBC_2" is wrong event name. >> Error: Failed to add events. >> ===== >> >> This failure was caused by a versioned suffix symbol. >> With this fix, perf probe automatically cuts the >> suffix after @ as below. >> >> ===== >> # ./perf probe -x /lib64/libc-2.25.so malloc* >> Added new events: >> probe_libc:malloc_printerr (on malloc* in /usr/lib64/libc-2.25.so) >> probe_libc:malloc_consolidate (on malloc* in /usr/lib64/libc-2.25.so) >> probe_libc:malloc_check (on malloc* in /usr/lib64/libc-2.25.so) >> probe_libc:malloc_hook_ini (on malloc* in /usr/lib64/libc-2.25.so) >> probe_libc:malloc (on malloc* in /usr/lib64/libc-2.25.so) >> probe_libc:malloc_trim (on malloc* in /usr/lib64/libc-2.25.so) >> probe_libc:malloc_usable_size (on malloc* in /usr/lib64/libc-2.25.so) >> probe_libc:malloc_stats (on malloc* in /usr/lib64/libc-2.25.so) >> probe_libc:malloc_info (on malloc* in /usr/lib64/libc-2.25.so) >> probe_libc:mallochook (on malloc* in /usr/lib64/libc-2.25.so) >> probe_libc:malloc_get_state (on malloc* in /usr/lib64/libc-2.25.so) >> probe_libc:malloc_set_state (on malloc* in /usr/lib64/libc-2.25.so) > > Thanks for working on this! I'm now going over it, and one thing I > noticed was that the (on malloc*) on all the entries matched by that > wildcard, can I suggest that you expand it there as well? I.e. > > probe_libc:malloc_set_state (on malloc_set_state in /usr/lib64/libc-2.25.so) > > This way we'll now when aliases are used, and also for the versioning > case, i.e. to which version is a probe pointing? > > See also Paul Clarke's question and suggestion, which I agree, i.e. > instead of chopping off the version, just replace the chars with valid > ones or better, do what Paul suggests, be more flexible in interpreting > @, i.e. if it is a number and/or fails to point to any file, interpret > it as versioning. It's a nit, and subjective, but I'd favor checking for versioning first, then file. The namespaces are very unlikely to intersect, but I could foresee symbols like "sym@implA.c" and "sym@implB.c" more likely than a symbol in a file "GLIBC_2.2.5". Perhaps straying toward bikeshedding... PC