On Wed, Jun 16, 2021 at 1:36 AM Lorenz Bauer <lmb@xxxxxxxxxxxxxx> wrote: > > bpf2go is the Go equivalent of libbpf skeleton. The convention is that > the compiled BPF is checked into the repository to facilitate distributing > BPF as part of Go packages. To make this portable, bpf2go by default > generates both bpfel and bpfeb variants of the C. > > Using bpf_tracing.h is inherently non-portable since the fields of > struct pt_regs differ between platforms, so CO-RE can't help us here. > The only way of working around this is to compile for each target > platform independently. bpf2go can't do this by default since there > are too many platforms. > > Define the various PT_... macros when no target can be determined and > turn them into compilation failures. This works because bpf2go always > compiles for bpf targets, so the compiler fallback doesn't kick in. > Conditionally define __BPF_MISSING_TARGET so that we can inject a > more appropriate error message at build time. The user can then > choose which platform to target explicitly. > > Signed-off-by: Lorenz Bauer <lmb@xxxxxxxxxxxxxx> > --- Applied to bpf-next, thanks. But please use one of few "canonical" patch subject prefixes next time: - libbpf: - selftests/bpf: - bpftool: - bpf: (for kernel patches) We don't do ":each: folder: path:" prefixes, it's not necessary and is quite long. > tools/lib/bpf/bpf_tracing.h | 46 +++++++++++++++++++++++++++++++++---- > 1 file changed, 42 insertions(+), 4 deletions(-) > [...]
