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

[Arnaldo Carvalho de Melo <acme@kernel.org>]

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:
> > Hello all,
> > 
> > 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.

- Arnaldo