Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp885293pxb; Wed, 27 Oct 2021 14:27:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznL11PhkYrD30PVdtMya/7InY/Dd1UId88iUrEUht4Iy/9vGMBhxvGyeDMzI2gNovUSq1S X-Received: by 2002:a17:906:3542:: with SMTP id s2mr49852eja.379.1635370064193; Wed, 27 Oct 2021 14:27:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635370064; cv=none; d=google.com; s=arc-20160816; b=hQLUw840zFOiaWlBdhnD6vKcvr9+sxAVkUCyzNjVbPYoymj1Ou94Cq5oARxrZdmSqI VHkIsTFN+NqgCW0xgii6kNgkFlitc3t+4FOABNDfiP8aN1GLlhPimT2Uxcq+RtmjEJQ7 aLwTdShnth2nx367FXnHNxFd5pAm9CH95b969ZqD2jeJ1Xs8Hyvt6rvpKxeY4xNv4xd7 7Ie2gcHCwj19dFyKmvgKKE9SfJd1oCvTxTrqMIVgAteqWgpypk33ZssrUXwittRoRY25 7h+3JuZ1oz3tPEcsGQuh2+/2nOTj5GJPki7hKudK8JnjYr20TI+2Vdi8q1Atea2PiagM 3g9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=GPi9kOx9xF4tSdUOBFNnkYgZbNhl9xu3F/2bDyAEADo=; b=M6vnxtk7iKketnWcOYwpozBkI8dfnJC8/MUodhuHCxy6Bspj+dO+L+kxhe5tD2+Jaw VipW0IqAEnvsl9U4xkJjztH2GAk+jgnH/bYC0F7oRvd/Fkdl4/dokFk9IOXVbbN0hEhx HBLaZZ/CRZw2JTByDsrZeV7EFjR/kaWNMSLPmxmKtBe3qs3By/CApS6F8hEcIW5CKbX8 WT1PZnhyZoCBfkwoVYEN1wLbOGmWZcsfgSZcBBSyLzN2igP85sGTa2NP9cER0GUvyDTK bjYHBYky8obDjOx9Ry3faTVxyHIUqG6StWE1t4qwebmBCY2k8ZtuwgcQYzR1K5i+meOa 6aaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o2si1720430ejy.80.2021.10.27.14.27.20; Wed, 27 Oct 2021 14:27:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240122AbhJ0Mdn (ORCPT + 97 others); Wed, 27 Oct 2021 08:33:43 -0400 Received: from szxga08-in.huawei.com ([45.249.212.255]:26128 "EHLO szxga08-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231497AbhJ0Mdm (ORCPT ); Wed, 27 Oct 2021 08:33:42 -0400 Received: from dggeme762-chm.china.huawei.com (unknown [172.30.72.53]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4HfSg15f6dz1DHtb; Wed, 27 Oct 2021 20:29:17 +0800 (CST) Received: from huawei.com (10.67.189.2) by dggeme762-chm.china.huawei.com (10.3.19.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15; Wed, 27 Oct 2021 20:31:13 +0800 From: Lexi Shao To: CC: , , , , , , , , , , , , Subject: Re: [PATCH] perf symbol: ignore $a/$d symbols for ARM modules Date: Wed, 27 Oct 2021 20:31:08 +0800 Message-ID: <20211027123108.126944-1-shaolexi@huawei.com> X-Mailer: git-send-email 2.12.3 In-Reply-To: <1b7fa65a-7587-b7c4-2dc0-d0f389200671@arm.com> References: <1b7fa65a-7587-b7c4-2dc0-d0f389200671@arm.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.67.189.2] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggeme762-chm.china.huawei.com (10.3.19.108) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27/10/2021 18:24, James Clark wrote: >On 27/10/2021 10:52, Lexi Shao wrote: >> On ARM machine, kernel symbols from modules can be resolved to $a >> instead of printing the actual symbol name. Ignore symbols starting with >> "$" when building kallsyms rbtree. >> >> A sample stacktrace is shown as follows: >> >> c0f2e39c schedule_hrtimeout+0x14 ([kernel.kallsyms]) >> bf4a66d8 $a+0x78 ([test_module]) >> c0a4f5f4 kthread+0x15c ([kernel.kallsyms]) >> c0a001f8 ret_from_fork+0x14 ([kernel.kallsyms]) >> >> On ARM machine, $a/$d symbols are used by the compiler to mark the >> beginning of code/data part in code section. These symbols are filtered >> out when linking vmlinux(see scripts/kallsyms.c ignored_prefixes), but >> are left on modules. So there are $a symbols in /proc/kallsyms which >> share the same addresses with the actual module symbols and confuses perf >> when resolving symbols. > >Hi Lexi, > >Is it worth using or re-implementing the entire is_ignored_symbol() function >from scripts/kallsyms.c? It seems like this change only fixes one occurrence, >but is_ignored_symbol() has a big list of other cases. > >Unless those cases are different? > >Thanks >James Hi James, I don't think it's necessary to cover all the cases listed in is_ignored_symbol(). As long as the symbols are unique and not overlapping with each other, they should't cause problems in resolving symbols. So most of the cases in is_ignored_symbol() should be irrelevant. Lexi > >> >> After this patch, the module symbol name is printed: >> >> c0f2e39c schedule_hrtimeout+0x14 ([kernel.kallsyms]) >> bf4a66d8 test_func+0x78 ([test_module]) >> c0a4f5f4 kthread+0x15c ([kernel.kallsyms]) >> c0a001f8 ret_from_fork+0x14 ([kernel.kallsyms]) >> >> Signed-off-by: Lexi Shao >> --- >> tools/perf/util/symbol.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c >> index 0fc9a5410739..35116aed74eb 100644 >> --- a/tools/perf/util/symbol.c >> +++ b/tools/perf/util/symbol.c >> @@ -702,6 +702,10 @@ static int map__process_kallsym_symbol(void *arg, const char *name, >> if (!symbol_type__filter(type)) >> return 0; >> >> + /* Ignore local symbols for ARM modules */ >> + if (name[0] == '$') >> + return 0; >> + >> /* >> * module symbols are not sorted so we add all >> * symbols, setting length to 0, and rely on >> >