[PATCH bpf-next 0/4] libbpf: add bpf_program__insns() accessor

[Andrii Nakryiko <andrii@kernel.org>]

Add libbpf APIs to access BPF program instructions. Both before and after
libbpf processing (before and after bpf_object__load()). This allows to
inspect what's going on with BPF program assembly instructions as libbpf
performs its processing magic.

But in more practical terms, this allows to do a no-brainer BPF program
cloning, which is something you need when working with fentry/fexit BPF
programs to be able to attach the same BPF program code to multiple kernel
functions. Currently, kernel needs multiple copies of BPF programs, each
loaded with its own target BTF ID. retsnoop is one such example that
previously had to rely on bpf_program__set_prep() API to hijack program
instructions ([0] for before and after).

Speaking of bpf_program__set_prep() API and the whole concept of
multiple-instance BPF programs in libbpf, all that is scheduled for
deprecation in v0.7. It doesn't work well, it's cumbersome, and it will become
more broken as libbpf adds more functionality. So deprecate and remove it in
libbpf 1.0. It doesn't seem to be used by anyone anyways (except for that
retsnoop hack, which is now much cleaner with new APIs as can be seen in [0]).

  [0] https://github.com/anakryiko/retsnoop/pull/1

Andrii Nakryiko (4):
  libbpf: fix off-by-one bug in bpf_core_apply_relo()
  libbpf: add ability to fetch bpf_program's underlying instructions
  libbpf: deprecate multi-instance bpf_program APIs
  libbpf: deprecate ambiguously-named bpf_program__size() API

 tools/lib/bpf/libbpf.c   | 36 ++++++++++++++++++++++-----------
 tools/lib/bpf/libbpf.h   | 43 +++++++++++++++++++++++++++++++++++++---
 tools/lib/bpf/libbpf.map |  2 ++
 3 files changed, 66 insertions(+), 15 deletions(-)

-- 
2.30.2