Received-SPF: pass (google.com: domain of linux-kernel+bounces-186699-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240520083048.322863-1-sesse@google.com> <CAM9d7cgBZVfur8S3QC2woUA2C6O3Dme0YHP8PbFcwc_o0k-dWg@mail.gmail.com>
 <Zk5Mi7SliDOd8uO4@google.com>
In-Reply-To: <Zk5Mi7SliDOd8uO4@google.com>
From: Namhyung Kim <namhyung@kernel.org>
Date: Wed, 22 May 2024 13:46:35 -0700
Message-ID: <CAM9d7cjjH63CC8r-z33P4SCWw3x4NMxuSC1CovVHqpp-zXSf6g@mail.gmail.com>
Subject: Re: [PATCH v4 1/3] perf report: Support LLVM for addr2line()
To: "Steinar H. Gunderson" <sesse@google.com>
Cc: acme@kernel.org, linux-perf-users@vger.kernel.org, 
	linux-kernel@vger.kernel.org, irogers@google.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 22, 2024 at 12:50=E2=80=AFPM Steinar H. Gunderson <sesse@google=
com> 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