> 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. How do you suggest to match the types for the target BTF without simulating the CO-RE relocation? Are you suggesting to match them only by name? We want to generate the minimal BTF that is needed by a given object. Consider that we could generate these files for thousands of kernels, size is very important for us. For this reason we chose to simulate the relocation generating only the types (and members) that are really needed. > Either way, this is not libbpf's problem to solve. It's a tooling problem. I agree. When I started working on this I tried to implement it without using the libbpf relocation logic, but very soon I realized I was reimplementing the same logic. Another possibility we have considered is to expose this relocation logic in the libbpf API, however I fear it's too complicated and invasive too...
