From: Namhyung Kim <namhyung@kernel.org>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
James Clark <james.clark@linaro.org>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Ian Rogers <irogers@google.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: Perf doesn't display kernel symbols anymore (bisected commit 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array for addresses"))
Date: Mon, 6 Jan 2025 13:46:05 -0800 [thread overview]
Message-ID: <Z3xPHSrVInsc6W6I@google.com> (raw)
In-Reply-To: <752a31b0-4370-4f52-b7cc-45f0078c1d6c@csgroup.eu>
Hello,
On Mon, Jan 06, 2025 at 01:38:52PM +0100, Christophe Leroy wrote:
>
>
> Le 03/01/2025 à 17:26, Arnaldo Carvalho de Melo a écrit :
> > On Fri, Jan 03, 2025 at 01:40:24PM +0100, Christophe Leroy wrote:
> > > Le 03/01/2025 à 02:08, Arnaldo Carvalho de Melo a écrit :
> > > > > PerfTop: 524 irqs/sec kernel:51.1% exact: 0.0% lost: 0/0 drop: 0/0
> > > > > [4000Hz cpu-clock:ppp], (all, 1 CPU)
> > > > > -------------------------------------------------------------------------------
> >
> > > > > 17.18% [unknown] [k] 0xc0891c14
> > > > > 7.63% [unknown] [k] 0xc005f11c
> >
> > > > I think I hadn't notice this '[unknown]' one bit before :-\ the [k] is
> > > > there, so having unknown is odd
> > > Problem found, it's in maps__find_next_entry(), this leads to both
> > > map->start and map->end of kernel map being set to 0xc0000000, which leads
> > > to the failure of bsearch() in maps__find().
> >
> > Right, and since you don't have any module (CONFIG_MODULES not set),
> > and most machines do, that is when the buggy function is called:
> >
> > machine__create_kernel_maps()
> > if (!machine__get_running_kernel_start(machine, &name, &start, &end))
> > <SNIP>
> > if (end == ~0ULL) {
> > /* update end address of the kernel map using adjacent module address */
> > struct map *next = maps__find_next_entry(machine__kernel_maps(machine),
> > machine__kernel_map(machine));
> >
> > if (next) {
> > machine__set_kernel_mmap(machine, start, map__start(next));
> > map__put(next);
> > }
> > }
> > <SNIP>
> >
> > So machine__get_running_kernel_start() doesn't manage to fill end with
> > either because it doesn't find the ref_reloc_sym, one of:
> >
> > const char *ref_reloc_sym_names[] = {"_text", "_stext", NULL}
> >
> > And returns -1, so that first if block fails, and then start also
> > doesn't get set and remains 0, which doesn't seem to be the case, as you
> > get 0xc0000000 in it, or this fails:
> >
> > err = kallsyms__get_symbol_start(filename, "_edata", &addr);
> > if (err)
> > err = kallsyms__get_function_start(filename, "_etext", &addr);
> > if (!err)
> > *end = addr;
> >
>
> Indeed yes that one fails, because:
>
> ~# grep -e _stext -e _etext -e _edata /proc/kallsyms
> c0000000 T _stext
> c08b8000 D _etext
>
> So there is no _edata and _etext is not text
>
> $ ppc-linux-objdump -x vmlinux | grep -e _stext -e _etext -e _edata
> c0000000 g .head.text 00000000 _stext
> c08b8000 g .rodata 00000000 _etext
> c1378000 g .sbss 00000000 _edata
>
> Changing
>
> kallsyms__get_function_start(filename, "_etext", &addr);
>
> to
>
> kallsyms__get_symbol_start(filename, "_etext", &addr);
>
> works.
>
>
> The following change works as well:
>
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S
> b/arch/powerpc/kernel/vmlinux.lds.S
> index b4c9decc7a75..b7b2cd7e2a20 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -123,10 +123,11 @@ SECTIONS
> */
> *(.sfpr);
> *(.text.asan.* .text.tsan.*)
> +
> + . = ALIGN(PAGE_SIZE);
> + _etext = .;
> } :text
>
> - . = ALIGN(PAGE_SIZE);
> - _etext = .;
> PROVIDE32 (etext = .);
>
> /* Read-only data */
>
> As it leads to:
>
> ~# grep -e _stext -e _etext -e _edata /proc/kallsyms
> c0000000 T _stext
> c08b8000 T _etext
>
> $ ppc-linux-objdump -x vmlinux | grep -e _stext -e _etext -e _edata
> c0000000 g .head.text 00000000 _stext
> c08b8000 g .text 00000000 _etext
> c1378000 g .sbss 00000000 _edata
>
> So what is the most correct fix ? Change architectures link script or make
> perf _etext lookup more flexible, allowing non-text ?
>
> Looking at vmlinux.lds.S from various architectures, I have the feeling
> several of them are affected.
>
> Now, regarding _edata, what I see is:
>
> ~# tail -2 /proc/kallsyms
> c136a000 D __start___bug_table
> c1377c14 D __stop___bug_table
>
> And in System.map I have:
>
> c136a000 D __start___bug_table
> c1377c14 D __stop___bug_table
> c1378000 B __bss_start
> c1378000 B _edata
> c1378000 B initcall_debug
> c1378004 B reset_devices
>
> Should perf try to locate the very last symbol when it doesn't find _edata ?
> Or should architecture's link script be modified ? Otherwise commit
> 69a87a32f5cd ("perf machine: Include data symbols in the kernel map") is
> just pointless.
Let's go with kallsyms__get_symbol_start(). I think it's the most
straight-forward and simplest fix.
Thanks,
Namhyung
next prev parent reply other threads:[~2025-01-06 21:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-16 7:01 Perf doesn't display kernel symbols anymore (bisected commit 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array for addresses")) Christophe Leroy
2024-12-17 14:18 ` James Clark
2024-12-17 14:50 ` Christophe Leroy
2024-12-26 15:51 ` Arnaldo Carvalho de Melo
2025-01-02 14:41 ` Christophe Leroy
2025-01-02 17:52 ` Christophe Leroy
2025-01-02 18:19 ` Arnaldo Carvalho de Melo
2025-01-02 19:42 ` Christophe Leroy
2025-01-03 1:08 ` Arnaldo Carvalho de Melo
2025-01-03 6:33 ` Christophe Leroy
2025-01-03 12:40 ` Christophe Leroy
2025-01-03 16:26 ` Arnaldo Carvalho de Melo
2025-01-06 12:38 ` Christophe Leroy
2025-01-06 21:46 ` Namhyung Kim [this message]
2025-01-08 17:55 ` Christophe Leroy
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=Z3xPHSrVInsc6W6I@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.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.