linux-kernel - Re: [PATCH 1/1] tools: perf: 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] [day] [month] [year] [list]

Message-ID: <Z7ZXt_Qttdrw6rAQ@google.com>
Date: Wed, 19 Feb 2025 14:14:15 -0800
From: Namhyung Kim <namhyung@...nel.org>
To: Stephen Brennan <stephen.s.brennan@...cle.com>
Cc: Andi Kleen <ak@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-perf-users@...r.kernel.org,
	Adrian Hunter <adrian.hunter@...el.com>,
	"Liang, Kan" <kan.liang@...ux.intel.com>,
	James Clark <james.clark@...aro.org>, linux-kernel@...r.kernel.org,
	Chaitanya S Prakash <chaitanyas.prakash@....com>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Jiri Olsa <jolsa@...nel.org>, Mark Rutland <mark.rutland@....com>,
	Ian Rogers <irogers@...gle.com>
Subject: Re: [PATCH 1/1] tools: perf: support .gnu_debugdata for symbols

On Wed, Feb 19, 2025 at 01:57:25PM -0800, Stephen Brennan wrote:
> Namhyung Kim <namhyung@...nel.org> writes:
> > Hello,
> >
> > On Fri, Feb 14, 2025 at 11:30:26AM -0800, Andi Kleen wrote:
> >> Stephen Brennan <stephen.s.brennan@...cle.com> writes:
> >> >  	DSO_BINARY_TYPE__GUEST_KMODULE_COMP,
> >> > diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
> >> > index 66fd1249660a3..e578b7d406a69 100644
> >> > --- a/tools/perf/util/symbol-elf.c
> >> > +++ b/tools/perf/util/symbol-elf.c
> >> > @@ -6,6 +6,7 @@
> >> >  #include <string.h>
> >> >  #include <unistd.h>
> >> >  #include <inttypes.h>
> >> > +#include <lzma.h>
> >> 
> >> This needs some ifdefs in case lzma.h is not available?
> >
> > Right, should be guarded by HAVE_LZMA_SUPPORT.
> 
> Thank you both. Do you happen to have a preference on whether to do this
> inline with the HAVE_LZMA_SUPPORT guards, or whether to use a helper
> like lzma_decompress_to_file() with a temporary file (presumably one
> which is already unlinked...)?
> 
> I suppose the more I ask the question, the more it feels obvious that an
> unlinked temporary file would require less new code. Both because I
> could use the existing helper, and also because there would be no need
> to free() the data which we decompressed into memory. So unless you have
> strong opinions I guess I'll switch it over :)

Should be ok to use the existing helper but I guess you still need to
call close() once it's done with the data.  Also I think it's better
to add dummy functions in the compress.h when LZMA is not supported so
that the symbol code can be unaware of the configurations.

Thanks,
Namhyung