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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z8tSyzcHF2V7Lofx@x1>
Date: Fri, 7 Mar 2025 17:10:51 -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 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@...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.

- Arnaldo