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

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

Message-ID: <87zfihbnsq.fsf@oracle.com>
Date: Wed, 19 Feb 2025 13:57:25 -0800
From: Stephen Brennan <stephen.s.brennan@...cle.com>
To: Namhyung Kim <namhyung@...nel.org>, Andi Kleen <ak@...ux.intel.com>
Cc: 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

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 :)

Thanks,
Stephen