Skip to content

FEATURE: Make the LLVM disassembler an optional runtime dependency #262

Open

Description

@socketpair

Summary

On Fedora 43, installing bpftool pulls in llvm20-libs (~140 MiB) as a hard
dependency, even though the bpftool binary itself is ~730 KiB:

# dnf install bpftool
Installing:
 bpftool            x86_64   7.6.0-1.fc43    fedora   731.4 KiB
Installing dependencies:
 llvm20-filesystem  x86_64   20.1.8-2.fc43   fedora   0.0   B
 llvm20-libs        x86_64   20.1.8-2.fc43   fedora   139.7 MiB

The LLVM library is only used to disassemble JIT-compiled (native) programs,
i.e. bpftool prog dump jited. Every other use case works
without LLVM. For scripting, automation, and CI, dragging in ~140 MB of LLVM
just to have a single optional command available is a heavy cost.

Proposal

Load the LLVM disassembler lazily at runtime via dlopen/dlsym instead of
linking against it at build time. When prog dump jited is invoked and the
library is unavailable, fall back gracefully (libbfd, or an informative message).
This would remove the automatic ELF dependency on libLLVM.so, allowing distributions to make
LLVM a weak/optional dependency (e.g. RPM Recommends) rather than a hard one.

Prior art

The perf tool is solving the exact same problem (libLLVM/libcapstone
bloating dependencies for users who never disassemble) by dlopen-ing these
libraries at runtime, so distributions can ship them as a separate, optional
package:

Alternatives considered

  • Build with the libbfd disassembler instead of LLVM (smaller, but a build/
    packaging choice and subject to libbfd's unstable ABI).
  • Build with no disassembler at all (loses prog dump jited entirely).
  • Ship the disassembler in a separate binary (works, but less idiomatic for a
    single-binary tool; dlopen keeps the existing UX intact).

Environment

  • bpftool 7.6.0-1.fc43 (Fedora 43), x86_64

Activity

  1. changed the title [-]FEATURE: Title: Make the LLVM disassembler an optional runtime dependency[/-] [+]FEATURE: Make the LLVM disassembler an optional runtime dependency[/+] on May 30, 2026
  2. socketpair commented on May 30, 2026

    @socketpair
    Author

    A concrete approach:

    Move the LLVM disassembler into a small separate .so (e.g. libbpftool-llvm.so)
    that links libLLVM normally, and dlopen it only when prog dump jited needs it. The main binary then has no link-time dependency on libLLVM.

    The split follows the existing interface in jit_disasm.c: disasm_init(),
    init_context(), disassemble_insn(), destroy_context() go into the .so;
    disasm_print_insn() stays in the binary and drives the loop/JSON formatting.

  3. qmonnet commented on Jun 1, 2026

    @qmonnet
    Member

    Thanks for the suggestion. I'm not opposed to it, although we probably want to keep the disassembler built-in when libbfd is used. Do you plan to work on this?

  4. added a commit that references this issue on Jun 1, 2026
    778a2cd
  5. socketpair commented on Jun 1, 2026

    @socketpair
    Author

    @qmonnet Please review the PR

  6. added 5 commits that reference this issue on Jun 1, 2026
    1b0865c
    cdab051
    24f1102
    d8b28f4
    446ba79
  7. 7 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions