Fri Sep 16 2022 22:09:54 GMT+0100 (British Summer Time) ~ Daniel Borkmann <daniel@xxxxxxxxxxxxx> > On 9/11/22 10:14 PM, Quentin Monnet wrote: >> To disassemble instructions for JIT-ed programs, bpftool has relied on >> the libbfd library. This has been problematic in the past: libbfd's >> interface is not meant to be stable and has changed several times. For >> building bpftool, we have to detect how the libbfd version on the system >> behaves, which is why we have to handle features disassembler-four-args >> and disassembler-init-styled in the Makefile. When it comes to shipping >> bpftool, this has also caused issues with several distribution >> maintainers unwilling to support the feature (see for example Debian's >> page for binutils-dev, which ships libbfd: "Note that building Debian >> packages which depend on the shared libbfd is Not Allowed." [0]). >> >> For these reasons, we add support for LLVM as an alternative to libbfd >> for disassembling instructions of JIT-ed programs. Thanks to the >> preparation work in the previous commits, it's easy to add the library >> by passing the relevant compilation options in the Makefile, and by >> adding the functions for setting up the LLVM disassembler in file >> jit_disasm.c. > > Could you add more context around the LLVM lib? The motivation is that > libbfd's > interface is not meant to be stable and has changed several times. How > does this > look on the LLVM's library side? Also, for the 2nd part, what is > Debian's stance > related to the LLVM lib? Would be good if both is explained in the > commit message. > Right now it mainly reads 'that libbfd has all these issues, so we're > moving to > something else', so would be good to provide more context to the ready > why the > 'something else' is better than current one. Hi Daniel, This was based on two things. First, there is a note in LLVM's Developer Policy [0] stating that the stability for the C API is “best effort” and not guaranteed, but at least there is some effort to keep compatibility when possible (which hasn't really been the case for libbfd so far). I am under the impression that there is little intent for libbfd to be used outside of gdb/binutils. Second: the relevant .deb page does not caution against linking to the lib, as binutils-dev page does. I can add this info to the commit log for the next version. [0] https://llvm.org/docs/DeveloperPolicy.html#c-api-changes