Re: [PATCH v5 00/19] Support dynamic opening of capstone/llvm remove BUILD_NONDISTRO

[Ian Rogers <irogers@google.com>]

On Fri, Aug 22, 2025 at 11:52 PM Sam James <sam@gentoo.org> wrote:
>
> > A few months ago, objdump was the only way to get
> > source line support [0]. Is that still the case?
>
> ... or is this perhaps handled by "[PATCH v5 18/19] perf srcline:
> Fallback between addr2line implementations", in which case, shouldn't
> that really land first so people can try the LLVM impl and use the
> binutils one if it fails?

So my opinion, BUILD_NON_DISTRO isn't supported and the code behind it
should go away. Please don't do anything to the contrary or enable it
for your distribution - this was supposed to be implied by the name.
The forking and running addr2line gets around the license issue that
is GPLv3* but comes with a performance overhead. It also has a
maintenance overhead supporting llvm and binutil addr2line, when the
addr2line output changes things break, etc. (LLVM has been evolving
their output but I'm not aware of it breaking things yet). We should
(imo) delete the forking and running addr2line support, it fits the
billing of something we can do when capstone and libLLVM support
aren't there but the code is a hot mess and we don't do exhaustive
testing against the many addr2line flavors, the best case is buyer
beware. Capstone is derived from libLLVM, I'm not sure it makes sense
having 2 libraries for this stuff. There's libLLVM but what it
provides through a C API is a mess requiring the C++ shimming. Tbh, I
think most of what these libraries provide we should just get over
ourselves and provide in perf itself. For example, does it make sense
to be trying to add type annotations to objdump output, to just update
objdump or have a disassembler library where we can annotate things as
we see fit? Library bindings don't break when text output formats get
tweaked. Given we're doing so much dwarf processing, do we need a
library for that or should that just be in-house? We can side step
most of this mess by starting again in python as is being shown in the
textual changes that bring with it stuff like console flame graphs:
https://lore.kernel.org/lkml/CAP-5=fU=z8kcY4zjezoxSwYf9vczYzHztiMSBvJxdwwBPVWv2Q@mail.gmail.com/
So I think long term we make the perf tool minimal with minimal
dependencies (ie no addr2line, libLLVM, etc.), we work on having nice
stuff in the python stuff where we can reuse or build new libraries
for addr2line, objdump-ing, etc. Use >1 thread, use asyncio, etc.

For where we are now, ie no python stuff, BUILD_NON_DISTRO should go
away as nobody is maintaining it and hasn't for 2 years (what happens
when libbfd and libiberty change?). We should focus on making the best
of what we have via libraries/tools that are supported - while not
forcing the libraries to be there or making the perf binary massive by
dragging in say libLLVM. The patch series pushes in that direction and
I commend it to the reader.

No, reordering the patches to compare performance of binutils doesn't
make sense, just build with and without the patch series if you want
to do this, but also don't do this as BUILD_NON_DISTRO should go away.

Thanks,
Ian

* (As I understand the issue IANAL) GPLv3 and GPLv2 can't be linked
together. Why not just use GPLv3? A major issue for me is that GPLv3
adds a requirement for “Installation Information” to be provided,
which means placing a binary in a cryptographically signed OS
partition you'd need to reveal the signing key which defeats the
purpose of signing the partition to ensure you aren't hacked. I like
open source and using the code, I don't want to be hacked by giving to
the hackers my signing keys.