From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E099C433E0 for ; Thu, 28 Jan 2021 03:33:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CAA6960C3D for ; Thu, 28 Jan 2021 03:33:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231177AbhA1DdX (ORCPT ); Wed, 27 Jan 2021 22:33:23 -0500 Received: from mga06.intel.com ([134.134.136.31]:64683 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229530AbhA1DdV (ORCPT ); Wed, 27 Jan 2021 22:33:21 -0500 IronPort-SDR: 4GAoTuFXJmimnhVoeJMHbsuMuW6d78TNmCrjuwRnvnOmEg3LADJ8t8JYPJ400v1wAVVGLsKDw/ CgaqsMUhCbQg== X-IronPort-AV: E=McAfee;i="6000,8403,9877"; a="241701780" X-IronPort-AV: E=Sophos;i="5.79,381,1602572400"; d="scan'208";a="241701780" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2021 19:31:33 -0800 IronPort-SDR: /Jc3c5jYCj7kC1arPXYY9H/0QUKyDtq7ivr/H3f0v0YmkuXskfIvnjXSTUxpWD03sHZaOGpmQX QKdh4vvviHnQ== X-IronPort-AV: E=Sophos;i="5.79,381,1602572400"; d="scan'208";a="388577104" Received: from yjin15-mobl1.ccr.corp.intel.com (HELO [10.238.4.27]) ([10.238.4.27]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2021 19:31:28 -0800 Subject: Re: [PATCH 1/2] perf script: Support filtering by hex address To: Jiri Olsa Cc: acme@kernel.org, jolsa@kernel.org, peterz@infradead.org, mingo@redhat.com, alexander.shishkin@linux.intel.com, Linux-kernel@vger.kernel.org, ak@linux.intel.com, kan.liang@intel.com, yao.jin@intel.com References: <20210124232750.19170-1-yao.jin@linux.intel.com> <20210127222905.GD284633@krava> From: "Jin, Yao" Message-ID: <60d102fa-d98a-6182-0a1d-b78122fed574@linux.intel.com> Date: Thu, 28 Jan 2021 11:31:26 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210127222905.GD284633@krava> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jiri, On 1/28/2021 7:13 AM, Jiri Olsa wrote: >> @@ -709,6 +725,26 @@ int machine__resolve(struct machine *machine, struct addr_location *al, >> ret = strlist__has_entry(symbol_conf.sym_list, >> al_addr_str); >> } >> + if (!ret && al->map) { >> + snprintf(al_addr_str, sz, "0x%"PRIx64, >> + al->map->unmap_ip(al->map, al->addr)); >> + ret = strlist__has_entry(symbol_conf.sym_list, >> + al_addr_str); >> + if (!ret) { >> + /* Check for hex without "0x" prefix */ >> + snprintf(al_addr_str, sz, "%"PRIx64, >> + al->map->unmap_ip(al->map, al->addr)); >> + ret = strlist__has_entry(symbol_conf.sym_list, >> + al_addr_str); >> + } > that seems tricky.. what if user specify more leading zeros, > I think it'd be better to search intlist instead > > we could move all 'address' entries from sym_list to > new intlist (in symbol__init) and use it for this search > > jirka > intlist now only supports 'int' type. I'm considering to use 'long' to replace original 'int' in struct int_node. struct int_node { struct rb_node rb_node; - int i; + long i; void *priv; }; On 32 bits platform, sizeof(long) is 4, and on 64 bits platform, sizeof(long) is 8. So that should be OK for storing the values such as pid/tid and address. I'm not very clear why currently it uses 'int' for i in struct int_node, maybe something I don't understand correctly. Please correct me if my understanding is wrong. Thanks Jin Yao