Re: [PATCH v1 4/5] perf capstone: Support for dlopen-ing libcapstone.so

[Ian Rogers]

> > On Wed, Jan 22, 2025 at 2:27 PM Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
> > > I think reverse engineering the types is fragile.  Can we simply change
> > > to dlopen if libcapstone is available?

To understand the scope of the problem, here is the LLVM code:
https://github.com/googleprodkernel/linux-perf/blob/google_tools_master/tools/perf/util/llvm.c#L22
3 typedefs and 5 #defines on 13 lines of code.

The capstone code is larger primarily due to needing to define cs_x86
(and its dependencies) which are used for extra detail in printing:
https://github.com/googleprodkernel/linux-perf/blob/google_tools_master/tools/perf/util/capstone.c#L23-L132
We could opt out of providing the extra detail if capstone.h isn't
present. I believe this can remove lines 49 to 123. This would mean
there would be 37 lines of reverse engineered types - 2 structs and 5
enums.

My feeling is that this isn't significant and better than returning
errors for capstone/llvm, having #ifdefs/__maybe_unused for the cases
we lack the types throughout the code and relying on people building
noticing a warning to realize they need to install a dependency - the
alternative of failing the build if the capstone/LLVM header files
aren't present, and unless some NO_... build option isn't passed,
likely won't fly with perf developers.

Thanks,
Ian