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

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

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(-)