Re: [PATCH 1/1] tools: perf: support .gnu_debugdata for symbols

[Namhyung Kim <namhyung@kernel.org>]

On Wed, Feb 19, 2025 at 01:57:25PM -0800, Stephen Brennan wrote:
> Namhyung Kim <namhyung@kernel.org> writes:
> > Hello,
> >
> > On Fri, Feb 14, 2025 at 11:30:26AM -0800, Andi Kleen wrote:
> >> Stephen Brennan <stephen.s.brennan@oracle.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