mbox series

[bpf-next,0/7] bpftool: Add LLVM as default library for disassembling JIT-ed programs

Message ID 20220906133613.54928-1-quentin@isovalent.com (mailing list archive)
Headers show
Series bpftool: Add LLVM as default library for disassembling JIT-ed programs | expand

Message

Quentin Monnet Sept. 6, 2022, 1:36 p.m. UTC
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, hence the
detection of the two related features from the Makefile
(disassembler-four-args and disassembler-init-styled). When it comes to
shipping bpftool, this has also caused issues with several distribution
maintainers unwilling to support the feature (for example, Debian's page
for binutils-dev, libbfd's package, says: "Note that building Debian
packages which depend on the shared libbfd is Not Allowed.").

This patchset adds support for LLVM as the primary library for
disassembling instructions for JIT-ed programs.

We keep libbfd as a fallback. One reason for this is that currently it
works well, we have all we need in terms of features detection in the
Makefile, so it provides a fallback for disassembling JIT-ed programs if
libbfd is installed but LLVM is not. The other reason is that libbfd
supports nfp instruction for Netronome's SmartNICs and can be used to
disassemble offloaded programs, something that LLVM cannot do (Niklas
confirmed that the feature is still in use). However, if libbfd's interface
breaks again in the future, we might reconsider keeping support for it.

Quentin Monnet (7):
  bpftool: Define _GNU_SOURCE only once
  bpftool: Remove asserts from JIT disassembler
  bpftool: Split FEATURE_TESTS/FEATURE_DISPLAY definitions in Makefile
  bpftool: Group libbfd defs in Makefile, only pass them if we use
    libbfd
  bpftool: Refactor disassembler for JIT-ed programs
  bpftool: Add LLVM as default library for disassembling JIT-ed programs
  bpftool: Add llvm feature to "bpftool version"

 .../bpftool/Documentation/common_options.rst  |   8 +-
 tools/bpf/bpftool/Makefile                    |  65 +++--
 tools/bpf/bpftool/common.c                    |   2 +
 tools/bpf/bpftool/iter.c                      |   2 +
 tools/bpf/bpftool/jit_disasm.c                | 244 ++++++++++++++----
 tools/bpf/bpftool/main.c                      |  10 +
 tools/bpf/bpftool/main.h                      |  29 ++-
 tools/bpf/bpftool/map.c                       |   1 -
 tools/bpf/bpftool/net.c                       |   2 +
 tools/bpf/bpftool/perf.c                      |   2 +
 tools/bpf/bpftool/prog.c                      |  17 +-
 tools/bpf/bpftool/xlated_dumper.c             |   2 +
 12 files changed, 291 insertions(+), 93 deletions(-)

Comments

Niklas Söderlund Sept. 10, 2022, 7:41 p.m. UTC | #1
Hi Quentin,

Thanks for your work.

On 2022-09-06 14:36:06 +0100, 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, hence the
> detection of the two related features from the Makefile
> (disassembler-four-args and disassembler-init-styled). When it comes to
> shipping bpftool, this has also caused issues with several distribution
> maintainers unwilling to support the feature (for example, Debian's page
> for binutils-dev, libbfd's package, says: "Note that building Debian
> packages which depend on the shared libbfd is Not Allowed.").
> 
> This patchset adds support for LLVM as the primary library for
> disassembling instructions for JIT-ed programs.
> 
> We keep libbfd as a fallback. One reason for this is that currently it
> works well, we have all we need in terms of features detection in the
> Makefile, so it provides a fallback for disassembling JIT-ed programs if
> libbfd is installed but LLVM is not. The other reason is that libbfd
> supports nfp instruction for Netronome's SmartNICs and can be used to
> disassemble offloaded programs, something that LLVM cannot do (Niklas
> confirmed that the feature is still in use). However, if libbfd's interface
> breaks again in the future, we might reconsider keeping support for it.

I have tested the fallback method for NFP and it works as expected and 
one can dump the offloaded program. I know there is discussion about the 
output format of the LLVM path, but for the whole series from a NFP 
point of view,

Tested-by: Niklas Söderlund <niklas.soderlund@corigine.com>

> 
> Quentin Monnet (7):
>   bpftool: Define _GNU_SOURCE only once
>   bpftool: Remove asserts from JIT disassembler
>   bpftool: Split FEATURE_TESTS/FEATURE_DISPLAY definitions in Makefile
>   bpftool: Group libbfd defs in Makefile, only pass them if we use
>     libbfd
>   bpftool: Refactor disassembler for JIT-ed programs
>   bpftool: Add LLVM as default library for disassembling JIT-ed programs
>   bpftool: Add llvm feature to "bpftool version"
> 
>  .../bpftool/Documentation/common_options.rst  |   8 +-
>  tools/bpf/bpftool/Makefile                    |  65 +++--
>  tools/bpf/bpftool/common.c                    |   2 +
>  tools/bpf/bpftool/iter.c                      |   2 +
>  tools/bpf/bpftool/jit_disasm.c                | 244 ++++++++++++++----
>  tools/bpf/bpftool/main.c                      |  10 +
>  tools/bpf/bpftool/main.h                      |  29 ++-
>  tools/bpf/bpftool/map.c                       |   1 -
>  tools/bpf/bpftool/net.c                       |   2 +
>  tools/bpf/bpftool/perf.c                      |   2 +
>  tools/bpf/bpftool/prog.c                      |  17 +-
>  tools/bpf/bpftool/xlated_dumper.c             |   2 +
>  12 files changed, 291 insertions(+), 93 deletions(-)
> 
> -- 
> 2.34.1
>