Re: [PATCH v2 0/3] Support .gnu_debugdata for symbols in perf

[Stephen Brennan <stephen.s.brennan@oracle.com>]

Arnaldo Carvalho de Melo <acme@kernel.org> writes:
> On Fri, Mar 07, 2025 at 05:18:36PM -0300, Arnaldo Carvalho de Melo wrote:
[...]
> It has a way to use that section tho:
>
> ⬢ [acme@toolbox perf-tools-next]$ man eu-readelf | grep -A2 -- --elf-section
>                [--elf-section [section] ]
>                [-w|
>                 --debug-dump[=line,=decodedline,=info,=info+,=abbrev,=pubnames,=aranges,=macro,=frames,=str,=loc,=ranges,=gdb_index,=addr]]
> --
>        --elf-section [section]
>            Use the named SECTION (default .gnu_debugdata) as (compressed) ELF input data
>
> ⬢ [acme@toolbox perf-tools-next]$
>
> ⬢ [acme@toolbox perf-tools-next]$ eu-readelf --elf-section -s /bin/find | grep -w FUNC | grep -vw UNDEF | wc -l
> 339
> ⬢ [acme@toolbox perf-tools-next]$ eu-readelf --elf-section -s /bin/find | grep -w FUNC | grep -vw UNDEF | head
>     1: 00000000000056d0     35 FUNC    LOCAL  DEFAULT       17 entry_hashfunc
>     2: 0000000000005700     34 FUNC    LOCAL  DEFAULT       17 entry_comparator
>     3: 0000000000005920    121 FUNC    LOCAL  DEFAULT       17 subtree_has_side_effects
>     4: 00000000000059a0    992 FUNC    LOCAL  DEFAULT       17 worst_cost.part.0
>     5: 0000000000005d80    449 FUNC    LOCAL  DEFAULT       17 traverse_tree
>     6: 0000000000005f50     73 FUNC    LOCAL  DEFAULT       17 undangle_file_pointers
>     7: 0000000000005fa0     72 FUNC    LOCAL  DEFAULT       17 looks_like_expression
>     8: 0000000000006030    303 FUNC    LOCAL  DEFAULT       17 get_fts_info_name
>     9: 0000000000006190     35 FUNC    LOCAL  DEFAULT       17 inside_dir.part.0
>    10: 0000000000006330    451 FUNC    LOCAL  DEFAULT       17 pred_sanity_check
> ⬢ [acme@toolbox perf-tools-next]$

Wow, thank you for teaching me that!
I had been using:

  gdb /usr/bin/bash --batch -ex 'maint print msymbols'

Because I knew GDB had support for .gnu_debugdata. But the --elf-section
argument to eu-readelf is much more useful.

> So there we can find the new entries, such as the top one in the example
> profile session above:
>
> ⬢ [acme@toolbox perf-tools-next]$ eu-readelf --elf-section -s /bin/find | grep -w FUNC | grep -vw UNDEF | grep -w consider_visiting
>    48: 000000000000b460   2544 FUNC    LOCAL  DEFAULT       17 consider_visiting
> ⬢ [acme@toolbox perf-tools-next]$
>
> And trat address matches the resolution perf did with your patches:
>
> ⬢ [acme@toolbox perf-tools-next]$ perf report -v --stdio |& head
> build id event received for [vdso]: a2184b81fbbc08eff401d16259eca8ad5f9d8988 [20]
> build id event received for /usr/bin/find: 3faf3f04d1b31abc9e5ce8428110e424fd980a37 [20]
> build id event received for /usr/lib64/ld-linux-x86-64.so.2: 765f7ab0f3569ffe98de85864a0cedda9b686994 [20]
> build id event received for /usr/lib64/libc.so.6: c8c3fa52aaee3f5d73b6fd862e39e9d4c010b6ba [20]
> build id event received for [kernel.kallsyms]: c3fbb7df4dfb94762b1648bc65e4363e50f45585 [20]
> read_gnu_debugdata: using .gnu_debugdata of /usr/bin/find
> # To display the perf.data header info, please use --header/--header-only options.
> #
> #
> # Total Lost Samples: 0
> ⬢ [acme@toolbox perf-tools-next]$ perf report -v --stdio |& head -20
> build id event received for [vdso]: a2184b81fbbc08eff401d16259eca8ad5f9d8988 [20]
> build id event received for /usr/bin/find: 3faf3f04d1b31abc9e5ce8428110e424fd980a37 [20]
> build id event received for /usr/lib64/ld-linux-x86-64.so.2: 765f7ab0f3569ffe98de85864a0cedda9b686994 [20]
> build id event received for /usr/lib64/libc.so.6: c8c3fa52aaee3f5d73b6fd862e39e9d4c010b6ba [20]
> build id event received for [kernel.kallsyms]: c3fbb7df4dfb94762b1648bc65e4363e50f45585 [20]
> read_gnu_debugdata: using .gnu_debugdata of /usr/bin/find
> # To display the perf.data header info, please use --header/--header-only options.
> #
> #
> # Total Lost Samples: 0
> #
> # Samples: 163  of event 'cpu_core/cycles/Pu'
> # Event count (approx.): 68126524
> #
> # Overhead  Command  Shared Object                    Symbol
> # ........  .......  ...............................  .......................................................
> #
>      8.72%  find     /usr/bin/find                    0xb498
>      7.90%  find     /usr/lib64/libc.so.6             0xe51e0            B [.] __GI___readdir64
>      7.44%  find     /usr/lib64/libc.so.6             0xa77cd            B [.] _int_malloc
> ⬢ [acme@toolbox perf-tools-next]$
>
> The only strange thing was not having it resolved in the -v case, which
> I think its because you added a new type of DSO but didn't update the
> code that does the 'perf report -v' verbose case?
>
> I ran out of time, have to go AFK now, can you please take a look,
> Stephen?

Thanks for the catch. I double checked all the places where
DSO_BINARY_TYPE constants are enumerated, and it turns out I missed
adding an entry to

char dso__symtab_origin(const struct dso *dso) ...

I assume that the array defaulted to '\0' which terminated the string
too early for this line. Oops!

Most of the letters I would associate with ".gnu_debugdata" are
taken (namely, g/G for GNU, m/M for MiniDebugInfo, d/D for
debugdata...). So 'n', for the second letter of GNU, is my selection
unless you feel differently. With that change, the table is fixed for
"perf report -v". Here it is running against my test data focusing on a
symbol only found in .gnu_debugdata of bash:

$ ./perf report -v --stdio -i ~/repos/UEK6/perf.data 2>&1 | egrep yy_readline_get\|gnu_debugdata
read_gnu_debugdata: using .gnu_debugdata of /usr/bin/bash
unwind: yy_readline_get:ip = 0x55fdc4509dbe (0x33dbe)
unwind: yy_readline_get:ip = 0x55fdc4509dbe (0x33dbe)
unwind: yy_readline_get:ip = 0x55fdc4509dbe (0x33dbe)
unwind: yy_readline_get:ip = 0x55fdc4509dbe (0x33dbe)
unwind: yy_readline_get:ip = 0x55fdc4509dbe (0x33dbe)
unwind: yy_readline_get:ip = 0x55fdc4509dbe (0x33dbe)
read_gnu_debugdata: using .gnu_debugdata of /usr/bin/sed
read_gnu_debugdata: using .gnu_debugdata of /usr/bin/date
read_gnu_debugdata: using .gnu_debugdata of /usr/bin/sqlite3
read_gnu_debugdata: using .gnu_debugdata of /usr/bin/sleep
     0.20%     0.00%  bash     /usr/bin/bash                    0x55fdc4509dbe     n [.] yy_readline_get

I'll update the patch accordingly.

> DSO_BINARY_TYPE__GNU_DEBUGDATA should be handled at...
>
> int dso__read_binary_type_filename(const struct dso *dso,
>                                    enum dso_binary_type type,
>                                    char *root_dir, char *filename, size_t size)
>
> But you have it there, ok, I'll try to continue later.
>
> Other than that the patch looks great and makes use of this new mini
> symtab, excellent!

And thank you for your testing!

> - Arnaldo