* [PATCH] perf symbol: remove Rust symbol workarounds
@ 2025-12-23 17:52 Gary Guo
2025-12-23 19:50 ` Benno Lossin
2025-12-24 9:43 ` Miguel Ojeda
0 siblings, 2 replies; 3+ messages in thread
From: Gary Guo @ 2025-12-23 17:52 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Andi Kleen,
Dmitry Vyukov, Stephen Brennan
Cc: Arnaldo Carvalho de Melo, linux-perf-users, linux-kernel,
rust-for-linux, llvm
From: Gary Guo <gary@garyguo.net>
Due to an off-by-one error introduced in commit 73bbb94466fd ("kallsyms:
support "big" kernel symbols"), long symbols (which are currently only
produced by Rust) can have their symbol type being wrongly parsed by
kernel/kallsyms.c.
This has been fixed in commit f3f9f42232dee5 ("kallsyms: Fix wrong "big"
kernel symbol type read from procfs"), and these symbols are now
reported correctly.
Drop the workaround in perf symbol that filter out these symbol types.
Specifically, '1' and 'l' can never be generated by nm -- 'u' does
indicate GNU unique, however such symbols are only generated by G++ for
C++ templates, and are never generated by LLVM (LLVM generates weak
symbols in such cases instead). Therefore, the previous occurrence of
these symbols types must be due to the off-by-error and can be safely
removed.
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Gary Guo <gary@garyguo.net>
---
tools/perf/util/symbol.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 814f960fa8f8d..eabb218b4e195 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -106,19 +106,8 @@ static enum dso_binary_type binary_type_symtab[] = {
static bool symbol_type__filter(char __symbol_type)
{
- // Since 'U' == undefined and 'u' == unique global symbol, we can't use toupper there
- // 'N' is for debugging symbols, 'n' is a non-data, non-code, non-debug read-only section.
- // According to 'man nm'.
- // 'N' first seen in:
- // ffffffff9b35d130 N __pfx__RNCINvNtNtNtCsbDUBuN8AbD4_4core4iter8adapters3map12map_try_foldjNtCs6vVzKs5jPr6_12drm_panic_qr7VersionuINtNtNtBa_3ops12control_flow11ControlFlowB10_ENcB10_0NCINvNvNtNtNtB8_6traits8iterator8Iterator4find5checkB10_NCNvMB12_B10_13from_segments0E0E0B12_
- // a seemingly Rust mangled name
- // Ditto for '1':
- // root@x1:~# grep ' 1 ' /proc/kallsyms
- // ffffffffb098bc00 1 __pfx__RNCINvNtNtNtCsfwaGRd4cjqE_4core4iter8adapters3map12map_try_foldjNtCskFudTml27HW_12drm_panic_qr7VersionuINtNtNtBa_3ops12control_flow11ControlFlowB10_ENcB10_0NCINvNvNtNtNtB8_6traits8iterator8Iterator4find5checkB10_NCNvMB12_B10_13from_segments0E0E0B12_
- // ffffffffb098bc10 1 _RNCINvNtNtNtCsfwaGRd4cjqE_4core4iter8adapters3map12map_try_foldjNtCskFudTml27HW_12drm_panic_qr7VersionuINtNtNtBa_3ops12control_flow11ControlFlowB10_ENcB10_0NCINvNvNtNtNtB8_6traits8iterator8Iterator4find5checkB10_NCNvMB12_B10_13from_segments0E0E0B12_
char symbol_type = toupper(__symbol_type);
- return symbol_type == 'T' || symbol_type == 'W' || symbol_type == 'D' || symbol_type == 'B' ||
- __symbol_type == 'u' || __symbol_type == 'l' || __symbol_type == 'N' || __symbol_type == '1';
+ return symbol_type == 'T' || symbol_type == 'W' || symbol_type == 'D' || symbol_type == 'B';
}
static int prefix_underscores_count(const char *str)
base-commit: b927546677c876e26eba308550207c2ddf812a43
--
2.51.2
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] perf symbol: remove Rust symbol workarounds
2025-12-23 17:52 [PATCH] perf symbol: remove Rust symbol workarounds Gary Guo
@ 2025-12-23 19:50 ` Benno Lossin
2025-12-24 9:43 ` Miguel Ojeda
1 sibling, 0 replies; 3+ messages in thread
From: Benno Lossin @ 2025-12-23 19:50 UTC (permalink / raw)
To: Gary Guo, Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, Andi Kleen, Dmitry Vyukov,
Stephen Brennan
Cc: Arnaldo Carvalho de Melo, linux-perf-users, linux-kernel,
rust-for-linux, llvm
On Tue Dec 23, 2025 at 6:52 PM CET, Gary Guo wrote:
> From: Gary Guo <gary@garyguo.net>
>
> Due to an off-by-one error introduced in commit 73bbb94466fd ("kallsyms:
> support "big" kernel symbols"), long symbols (which are currently only
> produced by Rust) can have their symbol type being wrongly parsed by
> kernel/kallsyms.c.
>
> This has been fixed in commit f3f9f42232dee5 ("kallsyms: Fix wrong "big"
> kernel symbol type read from procfs"), and these symbols are now
> reported correctly.
>
> Drop the workaround in perf symbol that filter out these symbol types.
>
> Specifically, '1' and 'l' can never be generated by nm -- 'u' does
> indicate GNU unique, however such symbols are only generated by G++ for
> C++ templates, and are never generated by LLVM (LLVM generates weak
> symbols in such cases instead). Therefore, the previous occurrence of
> these symbols types must be due to the off-by-error and can be safely
Typo: off-by-one error
Cheers,
Benno
> removed.
>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: Miguel Ojeda <ojeda@kernel.org>
> Signed-off-by: Gary Guo <gary@garyguo.net>
> ---
> tools/perf/util/symbol.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] perf symbol: remove Rust symbol workarounds
2025-12-23 17:52 [PATCH] perf symbol: remove Rust symbol workarounds Gary Guo
2025-12-23 19:50 ` Benno Lossin
@ 2025-12-24 9:43 ` Miguel Ojeda
1 sibling, 0 replies; 3+ messages in thread
From: Miguel Ojeda @ 2025-12-24 9:43 UTC (permalink / raw)
To: Gary Guo
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Ian Rogers, Adrian Hunter, James Clark, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Andi Kleen,
Dmitry Vyukov, Stephen Brennan, Arnaldo Carvalho de Melo,
linux-perf-users, linux-kernel, rust-for-linux, llvm
On Tue, Dec 23, 2025 at 6:54 PM Gary Guo <gary@kernel.org> wrote:
>
> Drop the workaround in perf symbol that filter out these symbol types.
>
> Specifically, '1' and 'l' can never be generated by nm -- 'u' does
> indicate GNU unique, however such symbols are only generated by G++ for
> C++ templates, and are never generated by LLVM (LLVM generates weak
> symbols in such cases instead). Therefore, the previous occurrence of
> these symbols types must be due to the off-by-error and can be safely
> removed.
Thanks Gary, this indeed should go away now.
Should we mention `N` which is also removed? (i.e. you mention all the
others that got removed in the paragraph above).
In addition, should we remove the `__` prefix in the parameter name?
It was added in the commit that added `u`.
For context, the commits that added this were (probably useful to
mention in the commit message):
945f50036169 ("perf symbols: Handle 'N' symbols in /proc/kallsyms")
4d728bb93bab ("perf symbols: Handle 'u' and 'l' symbols in /proc/kallsyms")
With the notes above considered:
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Cheers,
Miguel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-12-24 9:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-23 17:52 [PATCH] perf symbol: remove Rust symbol workarounds Gary Guo
2025-12-23 19:50 ` Benno Lossin
2025-12-24 9:43 ` Miguel Ojeda
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox