On Wed, Oct 27, 2021 at 1:37 PM Mauricio Vásquez <mauricio@xxxxxxxxxx> wrote: > > This commit implements a new set of "bpf_reloc_info__" functions for > generating a BTF file with the types a given set of eBPF objects need > for their CO-RE relocations. This code reuses all the existing CO-RE > logic (candidate lookup, matching, etc). The workflow is the same as > when an eBPF program is being loaded, but instead of patching the eBPF > instruction, we save the type involved in the relocation. > > A new struct btf_reloc_info is defined to save the BTF types needed by a > set of eBPF objects. It is created with the bpf_reloc_info__new() > function and populated with bpf_object__reloc_info_gen() for each eBPF > object, finally the BTF file is generated with > bpf_reloc_info__get_btf(). Please take at a look at BTFGen[0] to get a > complete example of how this API can be used. > > bpf_object__reloc_info_gen() ends up calling btf_reloc_info_gen_field() > that uses the access spec to add all the types needed by a given > relocation. The root type is added and, if it is a complex type, like a > struct or union, the members involved in the relocation are added as > well. References are resolved and all referenced types are added. This > function can be called multiple times to add the types needed for > different objects into the same struct btf_reloc_info, this allows the > user to create a BTF file that contains the BTF information for multiple > eBPF objects. > > The bpf_reloc_info__get_btf() generates the BTF file from a given struct > btf_reloc_info. This function first creates a new BTF object and copies > all the types saved in the struct btf_reloc_info there. For structures > and unions, only the members involved in a relocation are copied. While > adding the types to the new BTF object, a map is filled with the type > IDs on the old and new BTF structures. This map is then used later on > to fix all the IDs in the new BTF object. > > Right now only support for field based CO-RE relocations is supported. > > [0]: https://github.com/kinvolk/btfgen > > Signed-off-by: Mauricio Vásquez <mauricio@xxxxxxxxxx> > Signed-off-by: Rafael David Tinoco <rafael.tinoco@xxxxxxxxxxx> > Signed-off-by: Lorenzo Fontana <lorenzo.fontana@xxxxxxxxxx> > --- I don't think it's necessary for libbpf to expose all these new APIs. The format of CO-RE relocations and .BTF.ext is open and fixed. You don't really need to simulate full CO-RE relocation logic to figure out which types are necessary. Just go over all .BTF.ext records for CO-RE relocations, parse spec (simple format as well) and see which fields are accessed. The only extra bit is ignoring ___<suffix>, that's it. bpftool (or whatever other tool that's going to be used for this) can do that on its own by using existing libbpf APIs to work with BTF. Good bit of optimization would be to only emit forward declarations for structs that are never used, but are referenced by structs that are used. Either way, this is not libbpf's problem to solve. It's a tooling problem. > tools/lib/bpf/Makefile | 2 +- > tools/lib/bpf/libbpf.c | 28 ++- > tools/lib/bpf/libbpf.h | 4 + > tools/lib/bpf/libbpf.map | 5 + > tools/lib/bpf/relo_core.c | 514 +++++++++++++++++++++++++++++++++++++- > tools/lib/bpf/relo_core.h | 11 +- > 6 files changed, 554 insertions(+), 10 deletions(-) > [...]
