linux-kernel - Re: [PATCH v8 0/3] Capstone/llvm dlopen support

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] [day] [month] [year] [list]
Message-ID: <CAP-5=fW7YViusbdr9uZ_wSg5cwAPcdnysGbfuytKyYw6cbQa4g@mail.gmail.com>
Date: Thu, 8 Jan 2026 13:32:47 -0800
From: Ian Rogers <irogers@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, 
	Ian Rogers <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>, 
	Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <nick.desaulniers+lkml@...il.com>, 
	Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>, 
	Charlie Jenkins <charlie@...osinc.com>, "Masami Hiramatsu (Google)" <mhiramat@...nel.org>, 
	James Clark <james.clark@...aro.org>, Collin Funk <collin.funk1@...il.com>, 
	Dmitry Vyukov <dvyukov@...gle.com>, linux-perf-users@...r.kernel.org, 
	linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH v8 0/3] Capstone/llvm dlopen support

On Tue, Oct 7, 2025 at 9:38 AM Ian Rogers <irogers@...gle.com> wrote:
>
> Linking against libcapstone and libLLVM can be a significant increase
> in dependencies and file size if building statically. The dependencies
> are also quite cumbersome if bringing perf into a distribution. For
> something like `perf record` the disassembler and addr2line
> functionality of libcapstone and libLLVM won't be used. These patches
> support dynamically loading these libraries using dlopen and then
> calling the appropriate functions found using dlsym. Using dlopen
> allows libcapstone and libLLVM to be installed separately to perf and
> when that's done the performance will improve as separate commands for
> objdump and addr2line won't be invoked.
>
> The patch series adds perf_ variants of the capstone/llvm functions
> that will either directly call the function or (NO_CAPSTONE=1 and
> NO_LIBLLVM=1 cases) use dlopen/dlsym to discover and then call the
> function. To support the function signatures when
> HAVE_LIBCAPSTONE_SUPPORT and HAVE_LIBLLVM_SUPPORT aren't defined
> prototypes generated using pahole are given. This avoids requiring
> libcapstone or libLLVM for the sake of the header files. It also
> avoids having a build where neither dlopen or dynamic linking against
> libcapstone or libLLVM is supported. There are other possibilities in
> how to organize this, but the chosen approach was done so for the
> simplicity and cleanliness of the code.
>
> The addr2line LLVM functionality is written in C++. To avoid linking
> against libLLVM for this, a new LIBLLVM_DYNAMIC option is added where
> the C++ code with the libLLVM dependency will be built into a
> libperf-llvm.so and that dlsym-ed and called against. Ideally LLVM
> would extend their C API to avoid this.
>
> v8: Rebase down to 3 patches. Update commit and cover messages.
> v7: Refactor now the first 5 patches, that largely moved code around,
>     have landed. Move the dlopen code to the end of the series so that
>     the first 8 patches can be picked improving capstone/LLVM support
>     without adding the dlopen code. Rename the cover letter and
>     disassembler cleanup patches.
> v6: Refactor the libbfd along with capstone and LLVM, previous patch
>     series had tried to avoid this by just removing the deprecated
>     BUILD_NONDISTRO code. Remove the libtracefs removal into its own
>     patch.
> v5: Rebase and comment typo fix.
> v4: Rebase and addition of a patch removing an unused struct variable.
> v3: Add srcline addr2line fallback trying LLVM first then forking a
>     process. This came up in conversation with Steinar Gunderson
>     <sesse@...gle.com>.
>     Tweak the cover letter message to try to address Andi Kleen's
>     <ak@...ux.intel.com> feedback that the series doesn't really
>     achieve anything.
> v2: Add mangling of the function names in libperf-llvm.so to avoid
>     potential infinite recursion. Add BPF JIT disassembly support to
>     LLVM and capstone. Add/rebase the BUILD_NONDISTRO cleanup onto the
>     series from:
>     https://lore.kernel.org/lkml/20250111202851.1075338-1-irogers@google.com/
>     Some other minor additional clean up.
>
> Ian Rogers (3):
>   perf capstone: Support for dlopen-ing libcapstone.so
>   perf llvm: Support for dlopen-ing libLLVM.so
>   perf llvm: Mangle libperf-llvm.so function names

Ping.

Thanks,
Ian

>  tools/perf/Makefile.config         |  13 ++
>  tools/perf/Makefile.perf           |  24 ++-
>  tools/perf/tests/make              |   2 +
>  tools/perf/util/Build              |   2 +-
>  tools/perf/util/capstone.c         | 285 +++++++++++++++++++++++++----
>  tools/perf/util/llvm-c-helpers.cpp | 120 +++++++++++-
>  tools/perf/util/llvm-c-helpers.h   |  24 ++-
>  tools/perf/util/llvm.c             | 273 ++++++++++++++++++++++++---
>  8 files changed, 660 insertions(+), 83 deletions(-)
>
> --
> 2.51.0.618.g983fd99d29-goog
>