Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mauricio/btfgen v6 #15

Closed
wants to merge 8 commits into from

Conversation

mauriciovasquezbernal
Copy link
Member

Another one for testing.

struct bpf_object_open_opts openopts = {};

openopts.sz = sizeof(struct bpf_object_open_opts);
openopts.btf_custom_path = strdup("./5.4.0-smaller.btf");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rafaeldtinoco is strdup() actually needed here? I think it's not needed because libbpf internally has some logic to call it: https://github.com/libbpf/libbpf/blob/528094c0c1465499d9cca1da30a28e89254b4be7/src/libbpf.c#L7025. WDYT?

Nobody and others added 4 commits February 9, 2022 15:24
BTFGen needs to run the core relocation logic in order to understand
what are the types involved in a given relocation.

Currently bpf_core_apply_relo() calculates and **applies** a relocation
to an instruction. Having both operations in the same function makes it
difficult to only calculate the relocation without patching the
instruction. This commit splits that logic in two different phases: (1)
calculate the relocation and (2) patch the instruction.

For the first phase bpf_core_apply_relo() is renamed to
bpf_core_calc_relo_insn() who is now only on charge of calculating the
relocation, the second phase uses the already existing
bpf_core_patch_insn(). bpf_object__relocate_core() uses both of them and
the BTFGen will use only bpf_core_calc_relo_insn().

Signed-off-by: Mauricio Vásquez <[email protected]>
Signed-off-by: Rafael David Tinoco <[email protected]>
Signed-off-by: Lorenzo Fontana <[email protected]>
Signed-off-by: Leonardo Di Donato <[email protected]>
Expose bpf_core_add_cands() and bpf_core_free_cands() to handle
candidates list.

Signed-off-by: Mauricio Vásquez <[email protected]>
Signed-off-by: Rafael David Tinoco <[email protected]>
Signed-off-by: Lorenzo Fontana <[email protected]>
Signed-off-by: Leonardo Di Donato <[email protected]>
This command is implemented under the "gen" command in bpftool and the
syntax is the following:

$ bpftool gen min_core_btf INPUT OUTPUT OBJECT [OBJECT...]

INPUT is the file that contains all the BTF types for a kernel and
OUTPUT is the path of the minimize BTF file that will be created with
only the types needed by the objects.

Signed-off-by: Mauricio Vásquez <[email protected]>
Signed-off-by: Rafael David Tinoco <[email protected]>
Signed-off-by: Lorenzo Fontana <[email protected]>
Signed-off-by: Leonardo Di Donato <[email protected]>
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 <[email protected]>
Signed-off-by: Rafael David Tinoco <[email protected]>
Signed-off-by: Lorenzo Fontana <[email protected]>
Signed-off-by: Leonardo Di Donato <[email protected]>
The last part of the BTFGen algorithm is to create a new BTF object with
all the types that were recorded in the previous steps.

This function performs two different steps:
1. Add the types to the new BTF object by using btf__add_type(). Some
special logic around struct and unions is implemented to only add the
members that are really used in the field-based relocations. The type
ID on the new and old BTF objects is stored on a map.
2. Fix all the type IDs on the new BTF object by using the IDs saved in
the previous step.

Signed-off-by: Mauricio Vásquez <[email protected]>
Signed-off-by: Rafael David Tinoco <[email protected]>
Signed-off-by: Lorenzo Fontana <[email protected]>
Signed-off-by: Leonardo Di Donato <[email protected]>
Add "min_core_btf" feature explanation and one example of how to use it
to bpftool-gen man page.

Signed-off-by: Mauricio Vásquez <[email protected]>
Signed-off-by: Rafael David Tinoco <[email protected]>
Signed-off-by: Lorenzo Fontana <[email protected]>
Signed-off-by: Leonardo Di Donato <[email protected]>
This commit reuses the core_reloc test to check if the BTF files
generated with "bpftool gen min_core_btf" are correct. This introduces
test_core_btfgen() that runs all the core_reloc tests, but this time
the source BTF files are generated by using "bpftool gen min_core_btf".

The goal of this test is to check that the generated files are usable,
and not to check if the algorithm is creating an optimized BTF file.

Signed-off-by: Mauricio Vásquez <[email protected]>
Signed-off-by: Rafael David Tinoco <[email protected]>
Signed-off-by: Lorenzo Fontana <[email protected]>
Signed-off-by: Leonardo Di Donato <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants