Re: [PATCH bpf-next v7 4/7] bpftool: Implement "gen min_core_btf" logic
flat view
From: Quentin Monnet <hidden>
Date: 2022-02-18 16:21:08
Also in:
bpf
2022-02-15 17:58 UTC-0500 ~ Mauricio Vásquez [off-list ref]
quoted hunk ↗ jump to hunk
This commit implements the logic for the gen min_core_btf command. Specifically, it implements the following functions: - minimize_btf(): receives the path of a source and destination BTF files and a list of BPF objects. This function records the relocations for all objects and then generates the BTF file by calling btfgen_get_btf() (implemented in the following commit). - btfgen_record_obj(): loads the BTF and BTF.ext sections of the BPF objects and loops through all CO-RE relocations. It uses bpf_core_calc_relo_insn() from libbpf and passes the target spec to btfgen_record_reloc(), that calls one of the following functions depending on the relocation kind. - btfgen_record_field_relo(): uses the target specification to mark all the types that are involved in a field-based CO-RE relocation. In this case types resolved and marked recursively using btfgen_mark_type(). Only the struct and union members (and their types) involved in the relocation are marked to optimize the size of the generated BTF file. - btfgen_record_type_relo(): marks the types involved in a type-based CO-RE relocation. In this case no members for the struct and union types are marked as libbpf doesn't use them while performing this kind of relocation. Pointed types are marked as they are used by libbpf in this case. - btfgen_record_enumval_relo(): marks the whole enum type for enum-based relocations. Signed-off-by: Mauricio Vásquez <redacted> Signed-off-by: Rafael David Tinoco <redacted> Signed-off-by: Lorenzo Fontana <redacted> Signed-off-by: Leonardo Di Donato <redacted> --- tools/bpf/bpftool/Makefile | 8 +- tools/bpf/bpftool/gen.c | 455 ++++++++++++++++++++++++++++++++++++- 2 files changed, 457 insertions(+), 6 deletions(-)diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile index 94b2c2f4ad43..a137db96bd56 100644 --- a/tools/bpf/bpftool/Makefile +++ b/tools/bpf/bpftool/Makefile@@ -34,10 +34,10 @@ LIBBPF_BOOTSTRAP_INCLUDE := $(LIBBPF_BOOTSTRAP_DESTDIR)/include LIBBPF_BOOTSTRAP_HDRS_DIR := $(LIBBPF_BOOTSTRAP_INCLUDE)/bpf LIBBPF_BOOTSTRAP := $(LIBBPF_BOOTSTRAP_OUTPUT)libbpf.a -# We need to copy hashmap.h and nlattr.h which is not otherwise exported by -# libbpf, but still required by bpftool. -LIBBPF_INTERNAL_HDRS := $(addprefix $(LIBBPF_HDRS_DIR)/,hashmap.h nlattr.h) -LIBBPF_BOOTSTRAP_INTERNAL_HDRS := $(addprefix $(LIBBPF_BOOTSTRAP_HDRS_DIR)/,hashmap.h) +# We need to copy hashmap.h, nlattr.h, relo_core.h and libbpf_internal.h +# which are not otherwise exported by libbpf, but still required by bpftool. +LIBBPF_INTERNAL_HDRS := $(addprefix $(LIBBPF_HDRS_DIR)/,hashmap.h nlattr.h relo_core.h libbpf_internal.h) +LIBBPF_BOOTSTRAP_INTERNAL_HDRS := $(addprefix $(LIBBPF_BOOTSTRAP_HDRS_DIR)/,hashmap.h relo_core.h libbpf_internal.h) $(LIBBPF_OUTPUT) $(BOOTSTRAP_OUTPUT) $(LIBBPF_BOOTSTRAP_OUTPUT) $(LIBBPF_HDRS_DIR) $(LIBBPF_BOOTSTRAP_HDRS_DIR): $(QUIET_MKDIR)mkdir -p $@diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c index 8e066c747691..806001020841 100644 --- a/tools/bpf/bpftool/gen.c +++ b/tools/bpf/bpftool/gen.c@@ -14,6 +14,7 @@ #include <unistd.h> #include <bpf/bpf.h> #include <bpf/libbpf.h> +#include <bpf/libbpf_internal.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/mman.h>
Mauricio, did you try this patch on a system with an old Glibc (< 2.26) by any chance? Haven't tried yet but I expect this might break bpftool's build when COMPAT_NEED_REALLOCARRAY is set, because in that case gen.c pulls <bpf/libbpf_internal.h>, and then <tools/libc_compat.h> (through main.h). And libc_compat.h defines reallocarray(), which libbpf_internal.h poisons with a GCC pragma. At least this is what I observe when trying to add your patches to the kernel mirror, where reallocarray() is redefined unconditionally. I'm trying to figure out if we should fix this mirror-side, or kernel-side. (I suppose we still need this compatibility layer, Ubuntu 16.04 seems to use Glibc 2.23). Quentin