From nobody Fri Dec 19 05:26:51 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C18DFC43334 for ; Sun, 24 Jul 2022 06:00:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237328AbiGXGA3 (ORCPT ); Sun, 24 Jul 2022 02:00:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234667AbiGXGAX (ORCPT ); Sun, 24 Jul 2022 02:00:23 -0400 Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA2E21182B for ; Sat, 23 Jul 2022 23:00:22 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id d10so7726889pfd.9 for ; Sat, 23 Jul 2022 23:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=RQteeziS+VdRmbuMhvls5Rgisd3m+xGC6DUocVp6jm0=; b=TqNp2DIiNWNuzHGEkBGLf5GYC5DJF/ARUqsi2PIfmXWaBGdKHk6OCmnhdzqrTnT897 BIgC9KuBKYMQ2wBlb+2jp60B8qBncL+I08D5EyNDw7Vk5UuSyB5KuSh3y9UGey/+dvid SxfCINS9TZiYx2sqTVPo93oyttzX+eLwqrhXOedx1+/UFWd243nQOGmcyt21vMZV1Dql cshKTbuNrDnBA2SMjyba7IQHPirX3M5f2GutezDbNoyl5LosDs0gs4gcNd8qcU2DLRkC PZIVZFER/s9Zk4czUOmCxhgZS+f9RrtaJt+Re9JIFB76sU9NtxCyC02rPVKgkI/CivN/ f0VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=RQteeziS+VdRmbuMhvls5Rgisd3m+xGC6DUocVp6jm0=; b=tq3y3aUnV0C0R3sradJlTuwJFFnnJfQORAHsG7EEEa7osa8z5yxOpK/wnMk+H+2sDX hFgC4L4sG4ACd7gN2cRPvSqb1w0OUe/eG1Tu2Y4biDQiu50ycHhb/vV29r9UePiU8EQF A+7xFhbz1kUN/kVW3E9QLKaUI+zJrYVx7uTW/ZWkyyjSUuuLFhgPMA4oWDCORM2dlTxM 1iMYWmljyQRe6ShbRIr7BWvWLSdnzT7t+kSwDsER4n69qQE7NYn5hBh8RNMoUH8Iptd9 9whiioa7WAVzAA+FZE6fW9aN2WOlIG0SdMpSIbdaO0Ex6d8Kz6TeZ5sZBPLmOXAeRCMm BiaA== X-Gm-Message-State: AJIora/B3Y9xkCeDEDsmebkKPEbfW+EkfLXN0mdK7i8MhokuNh/qEztb noTbI1D260LTNoRxulyOlthp6A== X-Google-Smtp-Source: AGRyM1vG+4t1JQIPx0XI1ilAjiOISlULApvv5aJsHiGifISGfutlxnb4jjMRDpLvinVeHE7xHg1fWw== X-Received: by 2002:a05:6a00:4211:b0:52a:c86e:aba3 with SMTP id cd17-20020a056a00421100b0052ac86eaba3mr7540247pfb.41.1658642422122; Sat, 23 Jul 2022 23:00:22 -0700 (PDT) Received: from localhost (n058152077182.netvigator.com. [58.152.77.182]) by smtp.gmail.com with ESMTPSA id z11-20020a17090a7b8b00b001f21f5c81a5sm8051971pjc.19.2022.07.23.23.00.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Jul 2022 23:00:21 -0700 (PDT) From: Leo Yan To: Arnaldo Carvalho de Melo , Peter Zijlstra , Ingo Molnar , Mark Rutland , Jiri Olsa , Namhyung Kim , Alexander Shishkin , Ian Rogers , Fangrui Song , Chang Rui , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Leo Yan Subject: [PATCH v3 1/2] perf symbol: Correct address for bss symbols Date: Sun, 24 Jul 2022 14:00:12 +0800 Message-Id: <20220724060013.171050-2-leo.yan@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220724060013.171050-1-leo.yan@linaro.org> References: <20220724060013.171050-1-leo.yan@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" When using 'perf mem' and 'perf c2c', an issue is observed that tool reports the wrong offset for global data symbols. This is a common issue on both x86 and Arm64 platforms. Let's see an example, for a test program, below is the disassembly for its .bss section which is dumped with objdump: ... Disassembly of section .bss: 0000000000004040 : ... 0000000000004080 : ... 00000000000040c0 : ... 0000000000004100 : ... First we used 'perf mem record' to run the test program and then used 'perf --debug verbose=3D4 mem report' to observe what's the symbol info for 'buf1' and 'buf2' structures. # ./perf mem record -e ldlat-loads,ldlat-stores -- false_sharing.exe 8 # ./perf --debug verbose=3D4 mem report ... dso__load_sym_internal: adjusting symbol: st_value: 0x40c0 sh_addr: 0x4= 040 sh_offset: 0x3028 symbol__new: buf2 0x30a8-0x30e8 ... dso__load_sym_internal: adjusting symbol: st_value: 0x4080 sh_addr: 0x4= 040 sh_offset: 0x3028 symbol__new: buf1 0x3068-0x30a8 ... Perf tool relies on libelf to parse symbols, in executable and shared object files, 'st_value' holds a virtual address; 'sh_addr' is the address at which section's first byte should reside in memory, and 'sh_offset' is the byte offset from the beginning of the file to the first byte in the section. Perf tool uses below formula to convert symbol's memory address to file address: file_address =3D st_value - sh_addr + sh_offset ^ ` Memory address We can see the final adjusted address ranges for buf1 and buf2 are [0x30a8-0x30e8) and [0x3068-0x30a8) respectively, apparently this is incorrect, in the code, the structure for 'buf1' and 'buf2' specifies compiler attribute with 64-byte alignment. The problem happens for 'sh_offset', libelf returns it as 0x3028 which is not 64-byte aligned, combining with disassembly, it's likely libelf doesn't respect the alignment for .bss section, therefore, it doesn't return the aligned value for 'sh_offset'. Suggested by Fangrui Song, elf file contains program header which contains PT_LOAD segments, the fields p_vaddr and p_offset in PT_LOAD segments contain the execution info. A better choice for converting memory address to file address is using the formula: file_address =3D st_value - p_vaddr + p_offset This patch introduces function elf_read_program_header() which returns out the program header based on the passed 'st_value', then it uses above formula to calculate the symbol file address; and the debugging log is updated respectively. After applying the change: # ./perf --debug verbose=3D4 mem report ... dso__load_sym_internal: adjusting symbol: st_value: 0x40c0 p_vaddr: 0x3= d28 p_offset: 0x2d28 symbol__new: buf2 0x30c0-0x3100 ... dso__load_sym_internal: adjusting symbol: st_value: 0x4080 p_vaddr: 0x3= d28 p_offset: 0x2d28 symbol__new: buf1 0x3080-0x30c0 ... Fixes: f17e04afaff8 ("perf report: Fix ELF symbol parsing") Reported-by: Chang Rui Suggested-by: Fangrui Song Signed-off-by: Leo Yan Acked-by: Namhyung Kim --- tools/perf/util/symbol-elf.c | 45 ++++++++++++++++++++++++++++++++---- 1 file changed, 41 insertions(+), 4 deletions(-) diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c index ecd377938eea..ef6ced5c5746 100644 --- a/tools/perf/util/symbol-elf.c +++ b/tools/perf/util/symbol-elf.c @@ -233,6 +233,33 @@ Elf_Scn *elf_section_by_name(Elf *elf, GElf_Ehdr *ep, return NULL; } =20 +static int elf_read_program_header(Elf *elf, u64 vaddr, GElf_Phdr *phdr) +{ + size_t i, phdrnum; + u64 sz; + + if (elf_getphdrnum(elf, &phdrnum)) + return -1; + + for (i =3D 0; i < phdrnum; i++) { + if (gelf_getphdr(elf, i, phdr) =3D=3D NULL) + return -1; + + if (phdr->p_type !=3D PT_LOAD) + continue; + + sz =3D max(phdr->p_memsz, phdr->p_filesz); + if (!sz) + continue; + + if (vaddr >=3D phdr->p_vaddr && (vaddr < phdr->p_vaddr + sz)) + return 0; + } + + /* Not found any valid program header */ + return -1; +} + static bool want_demangle(bool is_kernel_sym) { return is_kernel_sym ? symbol_conf.demangle_kernel : symbol_conf.demangle; @@ -1209,6 +1236,7 @@ dso__load_sym_internal(struct dso *dso, struct map *m= ap, struct symsrc *syms_ss, sym.st_value); used_opd =3D true; } + /* * When loading symbols in a data mapping, ABS symbols (which * has a value of SHN_ABS in its st_shndx) failed at @@ -1262,11 +1290,20 @@ dso__load_sym_internal(struct dso *dso, struct map = *map, struct symsrc *syms_ss, goto out_elf_end; } else if ((used_opd && runtime_ss->adjust_symbols) || (!used_opd && syms_ss->adjust_symbols)) { + GElf_Phdr phdr; + + if (elf_read_program_header(syms_ss->elf, + (u64)sym.st_value, &phdr)) { + pr_warning("%s: failed to find program header for " + "symbol: %s st_value: %#" PRIx64 "\n", + __func__, elf_name, (u64)sym.st_value); + continue; + } pr_debug4("%s: adjusting symbol: st_value: %#" PRIx64 " " - "sh_addr: %#" PRIx64 " sh_offset: %#" PRIx64 "\n", __func__, - (u64)sym.st_value, (u64)shdr.sh_addr, - (u64)shdr.sh_offset); - sym.st_value -=3D shdr.sh_addr - shdr.sh_offset; + "p_vaddr: %#" PRIx64 " p_offset: %#" PRIx64 "\n", + __func__, (u64)sym.st_value, (u64)phdr.p_vaddr, + (u64)phdr.p_offset); + sym.st_value -=3D phdr.p_vaddr - phdr.p_offset; } =20 demangled =3D demangle_sym(dso, kmodule, elf_name); --=20 2.25.1 From nobody Fri Dec 19 05:26:51 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B33CEC433EF for ; Sun, 24 Jul 2022 06:00:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237565AbiGXGAb (ORCPT ); Sun, 24 Jul 2022 02:00:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235473AbiGXGA0 (ORCPT ); Sun, 24 Jul 2022 02:00:26 -0400 Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC2C713D5A for ; Sat, 23 Jul 2022 23:00:25 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id bh13so7663778pgb.4 for ; Sat, 23 Jul 2022 23:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=FMzC+sDhG88M55FlEFZSmk/W9b9O2exUBS8ELGOOwbI=; b=m/CAQYimVf1if5/iN4j9OObyDuMH02KfXenpyEwJjaW/lwMNZmKCs8evsbtZ9AX+TC L3KNZhY8r3CLJZKy5c37I5yolFlAoyk+rOJxMiGYkBQsIBIpqpyANun4ZQx5h9KEEsnn Fr+npRsNApUDXb0qggA5WMENw7wu98vXtuJeaxeSOPICFQqK2XUvBuzQhB3yW5VLFRKr my3AdB5llTwkb9N1WZvHxJMohJH9BuT5fADdt0H5E/e1OzqWFnqeVXYkle7njap7Zgzk KH1P7VmKu4IT+SH8uS46pyZ1ynL8gRkU4refwxiK4YxSSb9kLXghSDm2LZzoAgJ8O5ZF /mkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=FMzC+sDhG88M55FlEFZSmk/W9b9O2exUBS8ELGOOwbI=; b=Ic7qRIPC/Ey+Li18EUVKWRDT/wgUFC5x1SobDEyhSfjJwqRzMJ3qLdXTbKGS7nzKeu 9mJLPEPwKk2xFIuOzrn9rm5nCK2h5F70qLidzPVYe2YVgnrBXrw1sAuIthZLPv/kQjy+ yeGCZYwcqCohIlm/yF41isj4hHnxxc/hEaXMxUmCcnvl4Lnk9TEweibVeTK9ZG3XJ5xl 6shSgT+/VpFC635VqzxrC/OSipsJVoeufpK+1B9rtFbI+LfR5X8BgY1F9C1iEPKs/ScT WM/Ec9fBZJE6DQBCQGjHpqUSCDQcJt1RymYlbEHJy1Ntwympy8rA2vsj0LxwcKdEQerZ oa0Q== X-Gm-Message-State: AJIora+UWnCryUSTU1NcRDc1opnrHIiiPV/tJU1K5XtSVWku6Q3vjm3r G1AKH8YaRe6VFyvs6hQPRJaSFA== X-Google-Smtp-Source: AGRyM1vSGNkgQlC2X3AoZH/uNyq5YoxHZ3t0nHFE2VEEN5tnzhscAqsZxYjM8wF+NauGxaNj9nqNGw== X-Received: by 2002:a62:4e04:0:b0:52b:30f5:59b8 with SMTP id c4-20020a624e04000000b0052b30f559b8mr7253962pfb.37.1658642425112; Sat, 23 Jul 2022 23:00:25 -0700 (PDT) Received: from localhost (n058152077182.netvigator.com. [58.152.77.182]) by smtp.gmail.com with ESMTPSA id in2-20020a17090b438200b001ec85441515sm6308961pjb.24.2022.07.23.23.00.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Jul 2022 23:00:24 -0700 (PDT) From: Leo Yan To: Arnaldo Carvalho de Melo , Peter Zijlstra , Ingo Molnar , Mark Rutland , Jiri Olsa , Namhyung Kim , Alexander Shishkin , Ian Rogers , Fangrui Song , Chang Rui , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Leo Yan Subject: [PATCH v3 2/2] perf symbol: Skip symbols if SHF_ALLOC flag is not set Date: Sun, 24 Jul 2022 14:00:13 +0800 Message-Id: <20220724060013.171050-3-leo.yan@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220724060013.171050-1-leo.yan@linaro.org> References: <20220724060013.171050-1-leo.yan@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Some symbols are observed the 'st_value' field are zeros. E.g. libc.so.6 in Ubuntu contains a symbol '__evoke_link_warning_getwd' which resides in the '.gnu.warning.getwd' section. Unlike normal sections, such kind of sections are used for linker warning when a file calls deprecated functions, but they are not part of memory images, the symbols in these sections should be dropped. This patch checks the section attribute SHF_ALLOC bit, if the bit is not set, it skips symbols to avoid spurious ones. Suggested-by: Fangrui Song Signed-off-by: Leo Yan Acked-by: Namhyung Kim --- tools/perf/util/symbol-elf.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c index ef6ced5c5746..b3be5b1d9dbb 100644 --- a/tools/perf/util/symbol-elf.c +++ b/tools/perf/util/symbol-elf.c @@ -1255,6 +1255,17 @@ dso__load_sym_internal(struct dso *dso, struct map *= map, struct symsrc *syms_ss, =20 gelf_getshdr(sec, &shdr); =20 + /* + * If the attribute bit SHF_ALLOC is not set, the section + * doesn't occupy memory during process execution. + * E.g. ".gnu.warning.*" section is used by linker to generate + * warnings when calling deprecated functions, the symbols in + * the section aren't loaded to memory during process execution, + * so skip them. + */ + if (!(shdr.sh_flags & SHF_ALLOC)) + continue; + secstrs =3D secstrs_sym; =20 /* --=20 2.25.1