[PATCH next 1/1] perf symbols: Handle 'N' symbols in /proc/kallsyms

[PATCH next 1/1] perf symbols: Handle 'N' symbols in /proc/kallsyms

[Arnaldo Carvalho de Melo]

I started seeing this in recent Fedora 42 kernels:

  # uname -a
  Linux number 6.16.3-200.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Aug 23 17:02:17 UTC 2025 x86_64 GNU/Linux
  #
  # perf test vmlinux
    1: vmlinux symtab matches kallsyms                  : FAILED!
  #

Rust is enabled and these were the symbols causing the above failure,
i.e. found in vmlinux but not in /proc/kallsyms:

  $ grep -w N /proc/kallsyms
  0000000000000000 N __pfx__RNCINvNtNtNtCsbDUBuN8AbD4_4core4iter8adapters3map12map_try_foldjNtCs6vVzKs5jPr6_12drm_panic_qr7VersionuINtNtNtBa_3ops12control_flow11ControlFlowB10_ENcB10_0NCINvNvNtNtNtB8_6traits8iterator8Iterator4find5checkB10_NCNvMB12_B10_13from_segments0E0E0B12_
  0000000000000000 N _RNCINvNtNtNtCsbDUBuN8AbD4_4core4iter8adapters3map12map_try_foldjNtCs6vVzKs5jPr6_12drm_panic_qr7VersionuINtNtNtBa_3ops12control_flow11ControlFlowB10_ENcB10_0NCINvNvNtNtNtB8_6traits8iterator8Iterator4find5checkB10_NCNvMB12_B10_13from_segments0E0E0B12_
  $

So accept those 'N' symbols as well.

About them, from 'man nm':

           "N" The symbol is a debugging symbol.

           "n" The symbol is in a non-data, non-code, non-debug read-only section.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/util/symbol.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 3fed54de54016227..3d04382687d17d22 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -107,9 +107,14 @@ 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
 	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 == 'u' || __symbol_type == 'l' || __symbol_type == 'N';
 }
 
 static int prefix_underscores_count(const char *str)
-- 
2.51.0

Re: [PATCH next 1/1] perf symbols: Handle 'N' symbols in /proc/kallsyms

[Ian Rogers]

On Mon, Sep 8, 2025 at 1:54 PM Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> I started seeing this in recent Fedora 42 kernels:
>
>   # uname -a
>   Linux number 6.16.3-200.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Aug 23 17:02:17 UTC 2025 x86_64 GNU/Linux
>   #
>   # perf test vmlinux
>     1: vmlinux symtab matches kallsyms                  : FAILED!
>   #
>
> Rust is enabled and these were the symbols causing the above failure,
> i.e. found in vmlinux but not in /proc/kallsyms:
>
>   $ grep -w N /proc/kallsyms
>   0000000000000000 N __pfx__RNCINvNtNtNtCsbDUBuN8AbD4_4core4iter8adapters3map12map_try_foldjNtCs6vVzKs5jPr6_12drm_panic_qr7VersionuINtNtNtBa_3ops12control_flow11ControlFlowB10_ENcB10_0NCINvNvNtNtNtB8_6traits8iterator8Iterator4find5checkB10_NCNvMB12_B10_13from_segments0E0E0B12_
>   0000000000000000 N _RNCINvNtNtNtCsbDUBuN8AbD4_4core4iter8adapters3map12map_try_foldjNtCs6vVzKs5jPr6_12drm_panic_qr7VersionuINtNtNtBa_3ops12control_flow11ControlFlowB10_ENcB10_0NCINvNvNtNtNtB8_6traits8iterator8Iterator4find5checkB10_NCNvMB12_B10_13from_segments0E0E0B12_
>   $
>
> So accept those 'N' symbols as well.
>
> About them, from 'man nm':
>
>            "N" The symbol is a debugging symbol.
>
>            "n" The symbol is in a non-data, non-code, non-debug read-only section.
>
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: Ian Rogers <irogers@google.com>
> Cc: Miguel Ojeda <ojeda@kernel.org>
> Cc: James Clark <james.clark@linaro.org>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Kan Liang <kan.liang@linux.intel.com>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Reviewed-by: Ian Rogers <irogers@google.com>

Thanks,
Ian

> ---
>  tools/perf/util/symbol.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index 3fed54de54016227..3d04382687d17d22 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -107,9 +107,14 @@ 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
>         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 == 'u' || __symbol_type == 'l' || __symbol_type == 'N';
>  }
>
>  static int prefix_underscores_count(const char *str)
> --
> 2.51.0
>

Re: [PATCH next 1/1] perf symbols: Handle 'N' symbols in /proc/kallsyms

[Miguel Ojeda]

On Mon, Sep 8, 2025 at 10:54 PM Arnaldo Carvalho de Melo
<acme@kernel.org> wrote:
>
> +       // a seemingly Rust mangled name

Yeah, it is a Rust mangled symbol:

    core::iter::adapters::map::map_try_fold::<usize,
drm_panic_qr::Version, (),
core::ops::control_flow::ControlFlow<drm_panic_qr::Version>,
drm_panic_qr::Version,
core::iter::traits::iterator::Iterator::find::check<drm_panic_qr::Version,
<drm_panic_qr::Version>::from_segments::{closure#0}>::{closure#0}>::{closure#0}

From your `grep`, it seems that is the only one you see? If so, it
would be nice to understand why.

Cheers,
Miguel

Re: [PATCH next 1/1] perf symbols: Handle 'N' symbols in /proc/kallsyms

[Arnaldo Carvalho de Melo]

On September 9, 2025 7:57:40 AM GMT-03:00, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>On Mon, Sep 8, 2025 at 10:54 PM Arnaldo Carvalho de Melo
><acme@kernel.org> wrote:
>>
>> +       // a seemingly Rust mangled name
>
>Yeah, it is a Rust mangled symbol:
>
>    core::iter::adapters::map::map_try_fold::<usize,
>drm_panic_qr::Version, (),
>core::ops::control_flow::ControlFlow<drm_panic_qr::Version>,
>drm_panic_qr::Version,
>core::iter::traits::iterator::Iterator::find::check<drm_panic_qr::Version,
><drm_panic_qr::Version>::from_segments::{closure#0}>::{closure#0}>::{closure#0}
>
>From your `grep`, it seems that is the only one you see? If so, it
>would be nice to understand why.

Nope, there are 2 lines in the commit message, both zeroed as I did it as !root, I can see them as root.

Cheers,

- Arnaldo

Re: [PATCH next 1/1] perf symbols: Handle 'N' symbols in /proc/kallsyms

[Miguel Ojeda]

On Tue, Sep 9, 2025 at 1:17 PM Arnaldo Carvalho de Melo
<arnaldo.melo@gmail.com> wrote:
>
> Nope, there are 2 lines in the commit message, both zeroed as I did it as !root, I can see them as root.

Not sure I follow -- what I meant was whether you saw other `N`
symbols apart from that one (and its `__pfx_` prefixed variant).

Thanks!

Cheers,
Miguel