Removal of btf.Program
#522
Comments
|
We could solve many of these with flexible metadata in
We shouldn't support the user creating The downside to this schema is that per insn metadata only works well if most instructions don't have metadata, to keep the overhead low. It's also pretty pointer / indirection heavy. However stuffing things like |
|
I've put my WIP metadata implementation here: https://github.com/lmb/ebpf/commits/issue-515-instruction-meta |
Use per-instruction metadata to store func info, line info and CO-RE relocations. As a result, simply concatenating two Instruction slices preserves the ext_info without extra code to keep track of offsets. The simplest way to achieve is to assign ext_infos per section, before we split into individual functions. This also avoids having to split ext_infos in the first place. Storing ext_infos in metadata in turn allows / requires removing code that relies on stable offsets, the most notable being applying COREFixups. Instead of tracking which offset a fixup should be applied to we change coreRelocate to instead return results in the same order as CORERelocations are passed. In the caller we remember which instruction originated the relocation and apply the fixup directly instead of iterating all instructions once more. Instead of storing ExtInfos in Spec we split it off into a separate exported type. This makes more sense since every BTF ELF has a Spec, but ExtInfos are optional. It turns out that only the ELF loader doesn't care about ExtInfos in the first place, so we allow skipping ExtInfos altogether by introducing LoadSpecAndExtInfosFromReader. Finally we can remove btf.Program since we don't need an intermediate type to hold metadata anymore. Fixes cilium#522
Use per-instruction metadata to store func info, line info and CO-RE relocations. As a result, simply concatenating two Instruction slices preserves the ext_info without extra code to keep track of offsets. The simplest way to achieve is to assign ext_infos per section, before we split into individual functions. This also avoids having to split ext_infos in the first place. Storing ext_infos in metadata in turn allows / requires removing code that relies on stable offsets, the most notable being applying COREFixups. Instead of tracking which offset a fixup should be applied to we change coreRelocate to instead return results in the same order as CORERelocations are passed. In the caller we remember which instruction originated the relocation and apply the fixup directly instead of iterating all instructions once more. Instead of storing ExtInfos in Spec we split it off into a separate exported type. This makes more sense since every BTF ELF has a Spec, but ExtInfos are optional. It turns out that only the ELF loader doesn't care about ExtInfos in the first place, so we allow skipping ExtInfos altogether by introducing LoadSpecAndExtInfosFromReader. Finally we can remove btf.Program since we don't need an intermediate type to hold metadata anymore. Fixes cilium#522
Use per-instruction metadata to store func info, line info and CO-RE relocations. As a result, simply concatenating two Instruction slices preserves the ext_info without extra code to keep track of offsets. The simplest way to achieve is to assign ext_infos per section, before we split into individual functions. This also avoids having to split ext_infos in the first place. Storing ext_infos in metadata in turn allows / requires removing code that relies on stable offsets, the most notable being applying COREFixups. Instead of tracking which offset a fixup should be applied to we change coreRelocate to instead return results in the same order as CORERelocations are passed. In the caller we remember which instruction originated the relocation and apply the fixup directly instead of iterating all instructions once more. Instead of storing ExtInfos in Spec we split it off into a separate exported type. This makes more sense since every BTF ELF has a Spec, but ExtInfos are optional. It turns out that only the ELF loader doesn't care about ExtInfos in the first place, so we allow skipping ExtInfos altogether by introducing LoadSpecAndExtInfosFromReader. Finally we can remove btf.Program since we don't need an intermediate type to hold metadata anymore. Fixes cilium#522
Currently, a program's BTF info is kept in a separate structure, pointed to by
ebpf.ProgramSpec'sBTFfield. Now the use case for BTF has grown as substantially as it did, it's time to merge this data structure into the core types for ease of maintenance.Having this in a separate structure is both convenient (checking BTF presence is checking a single value) and inconvenient in some ways, but overall it's a burden to have the data spread out between two structs, especially when it comes to marshaling BTF info back into binary form.
My initial idea is to move things around as follows:
btf.TypeIDfield inebpf.ProgramSpecebpf.ProgramSpec, exported (?)#508 already made some small steps to remove the need for
FuncInfoandLineInfoto resemble their wire formats so closely. Ultimately, we should end up with something like[]*ProgramSpec.MarshalFuncInfos().More suggestions:
coreRelocateand get rid ofProgram?FuncInfos.Marshal?Type *Funcinstead of bare TypeIDThe text was updated successfully, but these errors were encountered: