All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: bpf <bpf@vger.kernel.org>,
	dwarves@vger.kernel.org, Jiri Olsa <jolsa@kernel.org>,
	Hao Luo <haoluo@google.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: Per-CPU variables in modules and pahole
Date: Wed, 9 Dec 2020 12:53:44 -0800	[thread overview]
Message-ID: <CAEf4BzZWabv_hExaANQyQ71L2JHYqXaT4hFj52w-poWoVYWKqQ@mail.gmail.com> (raw)

Hi,

I'm working on supporting per-CPU symbols in BPF/libbpf, and the
prerequisite for that is BTF data for .data..percpu data section and
variables inside that.

Turns out, pahole doesn't currently emit any BTF information for such
variables in kernel modules. And the reason why is quite confusing and
I can't figure it out myself, so was hoping someone else might be able
to help.

To repro, you can take latest bpf-next tree and add this to
bpf_testmod/bpf_testmod.c inside selftests/bpf:

$ git diff bpf_testmod/bpf_testmod.c
      diff --git
a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
index 2df19d73ca49..b2086b798019 100644
--- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
+++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
@@ -3,6 +3,7 @@
 #include <linux/error-injection.h>
 #include <linux/init.h>
 #include <linux/module.h>
+#include <linux/percpu-defs.h>
 #include <linux/sysfs.h>
 #include <linux/tracepoint.h>
 #include "bpf_testmod.h"
@@ -10,6 +11,10 @@
 #define CREATE_TRACE_POINTS
 #include "bpf_testmod-events.h"

+DEFINE_PER_CPU(int, bpf_testmod_ksym_dummy1) = -1;
+DEFINE_PER_CPU(int, bpf_testmod_ksym_percpu) = 123;
+DEFINE_PER_CPU(int, bpf_testmod_ksym_dummy2) = -1;
+
 noinline ssize_t
 bpf_testmod_test_read(struct file *file, struct kobject *kobj,
                      struct bin_attribute *bin_attr,

1. So the very first issue (that I'm going to ignore for now) is that
if I just added bpf_testmod_ksym_percpu, it would get addr == 0 and
would be ignored by the current pahole logic. So we need to fix that
for modules. Adding dummy1 and dummy2 takes care of this for now,
bpf_testmod_ksym_percpu has offset 4.

2. Second issue is more interesting. Somehow, when pahole iterates
over DWARF variables, the address of bpf_testmod_ksym_percpu is
reported as 0x10e74, not 4. Which totally confuses pahole because
according to ELF symbols, bpf_testmod_ksym_percpu symbol has value 4.
I tracked this down to dwarf_getlocation() returning 10e74 as number
field in expr.

But this seems wrong, because when looking at DWARF:

$ readelf -wi bpf_testmod.ko | grep bpf_testmod_ksym_percpu -B1 -A6
 <1><fbc5>: Abbrev Number: 97 (DW_TAG_variable)
    <fbc6>   DW_AT_name        : (indirect string, offset: 0x4afb):
bpf_testmod_ksym_percpu
    <fbca>   DW_AT_decl_file   : 5
    <fbcb>   DW_AT_decl_line   : 15
    <fbcc>   DW_AT_decl_column : 1
    <fbcd>   DW_AT_type        : <0xce>
    <fbd1>   DW_AT_external    : 1
    <fbd1>   DW_AT_location    : 9 byte block: 3 4 0 0 0 0 0 0 0
 (DW_OP_addr: 4)

You can see that addr is actually 4.

And ELF symbols agree:

$ readelf -a bpf_testmod.ko | grep bpf_testmod_ksym_percpu
   102: 0000000000000004     4 OBJECT  GLOBAL DEFAULT   33
bpf_testmod_ksym_percpu


I also can't seem to match 0x10e74 to anything in bpf_testmod.ko, no
section or anything like that.

So, help! Is this just a libdw bug? If yes, why don't we see it
anywhere else? If not, what am I missing and how can we make pahole
emit BTF data for variables in modules?

Thanks!


-- Andrii

             reply	other threads:[~2020-12-09 20:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09 20:53 Andrii Nakryiko [this message]
2020-12-10 16:43 ` Per-CPU variables in modules and pahole Jiri Olsa
2020-12-10 17:02   ` Andrii Nakryiko
2020-12-10 18:28     ` Hao Luo
2020-12-11  2:56       ` Andrii Nakryiko
2020-12-11  3:29         ` Andrii Nakryiko
2020-12-10 23:42     ` Jiri Olsa
2020-12-10 23:49       ` Andrii Nakryiko
2020-12-11  2:57         ` Andrii Nakryiko

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=CAEf4BzZWabv_hExaANQyQ71L2JHYqXaT4hFj52w-poWoVYWKqQ@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=acme@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dwarves@vger.kernel.org \
    --cc=haoluo@google.com \
    --cc=jolsa@kernel.org \
    /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.