From: Ilya Leoshkevich <iii@linux.ibm.com>
To: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: dwarves@vger.kernel.org, bpf@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Ilya Leoshkevich <iii@linux.ibm.com>
Subject: [PATCH dwarves] btf_encoder: Fix handling of percpu symbols on s390
Date: Tue, 12 Oct 2021 04:26:37 +0200 [thread overview]
Message-ID: <20211012022637.399365-1-iii@linux.ibm.com> (raw)
pahole does not generate VARs for percpu symbols on s390. A percpu
symbol definition on a typical x86_64 kernel looks like this:
[33] .data..percpu PROGBITS 0000000000000000 01c00000
^^^^^^^^^^^^^^^^ sh_addr
LOAD 0x0000000001c00000 0x0000000000000000 0x000000000286f000
^^^^^^^^^^^^^^^^^^ p_vaddr
13559: 000000000001ba50 4 OBJECT LOCAL DEFAULT 33 cpu_profile_flip
^^^^^^^^^^^^^^^^ st_value
Most importantly, .data..percpu's sh_addr is 0, and this is what pahole
is currently assuming. However, on s390 this is different:
[37] .data..percpu PROGBITS 00000000019cd000 018ce000
^^^^^^^^^^^^^^^^ sh_addr
LOAD 0x000000000136e000 0x000000000146d000 0x000000000146d000
^^^^^^^^^^^^^^^^^^ p_vaddr
80377: 0000000001ba1440 4 OBJECT WEAK DEFAULT 37 cpu_profile_flip
^^^^^^^^^^^^^^^^ st_value
Fix by restructuring the code to always use section-relative offsets
for symbols. Change the comment to focus on this invariant.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
---
btf_encoder.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/btf_encoder.c b/btf_encoder.c
index c341f95..16e90c3 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c
@@ -56,7 +56,8 @@ struct btf_encoder {
raw_output,
verbose,
force,
- gen_floats;
+ gen_floats,
+ is_rel;
uint32_t array_index_id;
struct {
struct var_info vars[MAX_PERCPU_VAR_CNT];
@@ -1104,6 +1105,13 @@ static int btf_encoder__collect_percpu_var(struct btf_encoder *encoder, GElf_Sym
if (encoder->verbose)
printf("Found per-CPU symbol '%s' at address 0x%" PRIx64 "\n", sym_name, addr);
+ /* Make sure addr is section-relative. For kernel modules (which are
+ * ET_REL files) this is already the case. For vmlinux (which is an
+ * ET_EXEC file) we need to subtract the section address.
+ */
+ if (!encoder->is_rel)
+ addr -= encoder->percpu.base_addr;
+
if (encoder->percpu.var_cnt == MAX_PERCPU_VAR_CNT) {
fprintf(stderr, "Reached the limit of per-CPU variables: %d\n",
MAX_PERCPU_VAR_CNT);
@@ -1195,12 +1203,9 @@ static int btf_encoder__encode_cu_variables(struct btf_encoder *encoder, struct
addr = var->ip.addr;
dwarf_name = variable__name(var);
- /* DWARF takes into account .data..percpu section offset
- * within its segment, which for vmlinux is 0, but for kernel
- * modules is >0. ELF symbols, on the other hand, don't take
- * into account these offsets (as they are relative to the
- * section start), so to match DWARF and ELF symbols we need
- * to negate the section base address here.
+ /* Make sure addr is section-relative. DWARF, unlike ELF,
+ * always contains virtual symbol addresses, so subtract
+ * the section address unconditionally.
*/
if (addr < encoder->percpu.base_addr || addr >= encoder->percpu.base_addr + encoder->percpu.sec_sz)
continue;
@@ -1322,6 +1327,8 @@ struct btf_encoder *btf_encoder__new(struct cu *cu, const char *detached_filenam
goto out_delete;
}
+ encoder->is_rel = ehdr.e_type == ET_REL;
+
switch (ehdr.e_ident[EI_DATA]) {
case ELFDATA2LSB:
btf__set_endianness(encoder->btf, BTF_LITTLE_ENDIAN);
--
2.31.1
next reply other threads:[~2021-10-12 2:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-12 2:26 Ilya Leoshkevich [this message]
2021-10-15 12:54 ` [PATCH dwarves] btf_encoder: Fix handling of percpu symbols on s390 Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211012022637.399365-1-iii@linux.ibm.com \
--to=iii@linux.ibm.com \
--cc=acme@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dwarves@vger.kernel.org \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.