All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.