linux-kernel - Re: [PATCH v4 1/3] perf report: Support LLVM for addr2line()

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: <CAM9d7cjjH63CC8r-z33P4SCWw3x4NMxuSC1CovVHqpp-zXSf6g@mail.gmail.com>
Date: Wed, 22 May 2024 13:46:35 -0700
From: Namhyung Kim <namhyung@...nel.org>
To: "Steinar H. Gunderson" <sesse@...gle.com>
Cc: acme@...nel.org, linux-perf-users@...r.kernel.org, 
	linux-kernel@...r.kernel.org, irogers@...gle.com
Subject: Re: [PATCH v4 1/3] perf report: Support LLVM for addr2line()

On Wed, May 22, 2024 at 12:50 PM Steinar H. Gunderson <sesse@...glecom> wrote:
>
> On Wed, May 22, 2024 at 10:27:06AM -0700, Namhyung Kim wrote:
> > I think it should support other DWARF use cases like
> > unwinding and type info?
>
> I don't actually know. I had a look, but could really only find
> documentation for _writing_ DWARF info. However, I've hardly used LLVM
> before, so it's entirely possible that I missed something.

Oh ok.  I guess it should be able to read when it knows how to write. :)
But anyway they are separate, nice-to-have issues.  I think we can
add them later.

>
> > I remember bfd objdump is sometimes faster than llvm-objdump
> > especially when no line numbers are requested IIRC.
>
> Hm, I've never seen that. But it's impossible to say for sure
> that no such case exists, of course.
>
> > Anyway, nice work.  Maybe we can implement other use cases
> > using LLVM and reduce the dependencies.
>
> It's possible to remove the libbfd dependency entirely if that's a goal,
> at least, but I don't know what the current thinking is. I'll be happy
> to take a stab at it (I guess it's possible to test the PE support with
> WINE fairly easily?).

Great!  Personally I found libbfd is hard to read (and use).  Hope
that libllvm is better in that pov.  I'm not sure if we all want to
remove the libbfd dependency but at least we can select one of
them at build time.  Maybe the same for libelf and libdw(fl) too.

>
> I found out that if compiling with an older compiler, LLVM changes to
> llvm::Optional and doesn't have .value_or(), so I need to fix that
> (the patch is trivial, but it means I need to post a v5, I guess).
> Is there anything else I need to do after that to get this merged?

Having symbol enumeration and demangling with LLVM would
be nice but not required to merge this work.  I'll take a deeper
look next week.  Please post v5.

Thanks,
Namhyung