Skip to contentSkip to conversation

perf symbol: remove Rust symbol workarounds

PATCH Superseded Gary Guo 3 participants 3 messages Dec 23, 2025 – Dec 24, 2025

Subsystems (2)
perf events Rust

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Gary Guo

author
#0 lore raw

PATCH 1/1 perf symbol: remove Rust symbol workarounds

From: Gary Guo <[email protected]>

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 <[email protected]>
Cc Miguel Ojeda <[email protected]>
Signed-off-by Gary Guo <[email protected]>
---
 tools/perf/util/symbol.c | 13 +------------
 1 file changed, 1 insertion(+), 12 deletions(-)
tools/perf/util/symbol.c +1 -12
index 814f960fa8f8d..eabb218b4e195 100644
@@ -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

Signature · 1 line
2.51.2
reviewer
#1 lore raw
Quoted 11 lines · Gary Guo

From: Gary Guo <[email protected]>

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.

Quoted 7 lines

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

Quoted 8 lines

removed.

Cc Arnaldo Carvalho de Melo <[email protected]>
Cc Miguel Ojeda <[email protected]>
Signed-off-by Gary Guo <[email protected]>
---
 tools/perf/util/symbol.c | 13 +------------
 1 file changed, 1 insertion(+), 12 deletions(-)
Acked-by on v1 1/1
#2 lore raw
In reply to Gary Guo
Quoted 9 lines · Gary Guo

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 <[email protected]>

Cheers,
Miguel