linux-kernel - Re: [PATCH v2 0/3] Support .gnu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z8tUmcIH1qTF6YTn@x1>
Date: Fri, 7 Mar 2025 17:18:33 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Stephen Brennan <stephen.s.brennan@...cle.com>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"Liang, Kan" <kan.liang@...ux.intel.com>,
	Mark Rutland <mark.rutland@....com>,
	Athira Rajeev <atrajeev@...ux.vnet.ibm.com>,
	Jiri Olsa <jolsa@...nel.org>, linux-kernel@...r.kernel.org,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	James Clark <james.clark@...aro.org>,
	Chaitanya S Prakash <chaitanyas.prakash@....com>,
	Ian Rogers <irogers@...gle.com>, linux-perf-users@...r.kernel.org,
	Adrian Hunter <adrian.hunter@...el.com>,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH v2 0/3] Support .gnu_debugdata for symbols in perf

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@...lbox 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@...lbox perf-tools-next]$ ldd ~/bin/perf | grep lzma
> 	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f77ac879000)
> ⬢ [acme@...lbox 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@...lbox 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@...lbox 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@...lbox 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