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

[Arnaldo Carvalho de Melo]

On Fri, Mar 07, 2025 at 05:10:55PM -0300, Arnaldo Carvalho de Melo wrote:
> On Wed, Feb 26, 2025 at 02:06:28PM -0800, Namhyung Kim wrote:
> > On Thu, Feb 20, 2025 at 10:55:08AM -0800, Stephen Brennan wrote:
> > > This series adds the ability to read symbols from the ".gnu_debugdata" section,
> > > an LZMA-compressed embedded ELF file which is supposed to contain additional ELF
> > > symbols. This is something that Fedora implemented (as "MiniDebuginfo" [1]).
> > > There are more details in v1. I've tested it with binaries that have
> > > .gnu_debugdata, and I've also ensured that the build & runtime work when LZMA is
> > > disabled.

> > > [1]: https://fedoraproject.org/wiki/Features/MiniDebugInfo

> > > Changes since v1:
> > > * Reuses the existing LZMA decompression helpers, rather than implementing a
> > >   new LZMA decompression loop. This does involve creating a temporary file, but
> > >   I think that actually makes things cleaner, since now the symsrc has a file
> > >   descriptor to close, rather than adding a new pointer that needs freeing.
> > > * I did also remove the pr_debug() for the case where there is no
> > >   ".gnu_debugdata" section. That's not really an error worth logging, that's
> > >   just normal operation.
> > > * I added a pr_debug() for the case where we successfully load .gnu_debugdata
> > >   so that it's easier to determine whether it gets used in tests.
> > 
> > Thanks, it'd be nice if anyone with a Fedora box could test this.
> 
> I'm trying to go thru this, testing with/without LZMA so that we can
> show the difference in symbol resolution, etc, but I've now stumbled on
> something that predates this, namely trying to build with NO_LZMA=1
> isn't disabling it:
 
> ⬢ [acme@toolbox perf-tools-next]$ rm -rf /tmp/build/$(basename $PWD)/ ; mkdir /tmp/build/$(basename $PWD)/ ; make NO_LZMA=1 O=/tmp/build/$(basename $PWD)/ -C tools/perf install-bin
> make: Entering directory '/home/acme/git/perf-tools-next/tools/perf'
>   BUILD:   Doing 'make -j28' parallel build
> 
> Auto-detecting system features:
> ...                                   libdw: [ on  ]
> ...                                   glibc: [ on  ]
> ...                                  libbfd: [ on  ]
> ...                          libbfd-buildid: [ on  ]
> ...                                  libelf: [ on  ]
> ...                                 libnuma: [ on  ]
> ...                  numa_num_possible_cpus: [ on  ]
> ...                                 libperl: [ on  ]
> ...                               libpython: [ on  ]
> ...                               libcrypto: [ on  ]
> ...                               libunwind: [ on  ]
> ...                             libcapstone: [ on  ]
> ...                               llvm-perf: [ on  ]
> ...                                    zlib: [ on  ]
> ...                                    lzma: [ on  ]
> <SNIP>
> 
> 
> ⬢ [acme@toolbox perf-tools-next]$ ldd ~/bin/perf | grep lzma
> 	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f77ac879000)
> ⬢ [acme@toolbox perf-tools-next]$
> 
> my hunch is that some other feature needs lzma support and ignores the
> explicit NO_LZMA=1 on the make command line when it should really be
> disabling whatever features needs it, not overriding the cmd line
> request.
> 
> I'm trying to investigate.

Its an interesting case, as this patch says, elfutils now depends on
liblzma, so:

⬢ [acme@toolbox perf-tools-next]$ rpm -qa | grep xz
xz-libs-5.4.6-3.fc40.x86_64
xz-5.4.6-3.fc40.x86_64
xz-devel-5.4.6-3.fc40.x86_64
⬢ [acme@toolbox perf-tools-next]$ rpm -e xz-devel
error: Failed dependencies:
	pkgconfig(liblzma) is needed by (installed) elfutils-devel-0.192-9.fc40.x86_64
	pkgconfig(liblzma) is needed by (installed) libxml2-devel-2.12.9-1.fc40.x86_64
	xz-devel(x86-64) is needed by (installed) libxml2-devel-2.12.9-1.fc40.x86_64
⬢ [acme@toolbox perf-tools-next]$

The NO_LZMA code in the perf build system should at this point either be
deleted, as elfutils is so critical for perf, or mean that outside of
elfutils, perf should make no use of lzma, which seems odd even with
some potentially marginal value.

So for testing this series I'll have to collect data before these
patches get applied, making sure we collect samples from symbols in
binaries with a MiniDebuginfo section, do a perf report, see them as
being not resolved after making sure we don't have its debuginfo files
installed and zapping whatever local debuginfo cache we have
(debuginfod, perfs, etc), apply the patches and then see if it gets more
symbols resolved by looking at the .gnu_debugdata section.

Ok, doing that now.

- Arnaldo