On Sat, Jun 1, 2024 at 12:22 AM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > On Tue, 2024-05-28 at 15:18 -0700, Andrii Nakryiko wrote: > > [...] > > > Speaking of which, for the next revision, can you also integrate all > > these new APIs into bpftool to handle the problem that Jose tried to > > solve? This might also expose any of the potential issues with API > > usage. > > Hi Andrii, > > Good foresight requesting to re-implement Jose's patch on top of the yay, I guess it was :) > new API. I did the changes you requested for v1 + tried to make the > bpftool changes, results are here: > > https://github.com/eddyz87/bpf/tree/libbpf-sort-for-dump-api-2 > > The attempt falls flat for the following pattern: > > #define __pai __attribute__((preserve_access_index)) > typedef struct { int x; } foo __pai; > > With the following clang error: > > t.c:2:31: error: 'preserve_access_index' attribute only applies to structs, unions, and classes > 2 | typedef struct { int x; } foo __pai; > > The correct syntax for this definition is as below: > > typedef struct { int x; } __pai foo; > > This cannot be achieved unless printing of typedefs is done by some > custom code in bpftool. Right, though in this case it probably is still achieved with using btf_dump__emit_type_decl() if bpftool detects TYPEDEF -> (anon) STRUCT pattern. But we can get deeper, thanks to horrendous C syntax: typedef struct { int x; } struct_arr[10]; I think it still is achievable with btf_dump__emit_type_decl() setting .field_name option to "__pai struct_arr". It does feel like a hack, of course, but should work. In general, typedef is equivalent to field definition (which is intentional by original C syntax inventors, I believe), so maybe that's one way to address this. > > So, it looks like we won't be able to ditch callbacks in the end. hopefully we can avoid this still, let's give it some more thought before we give up > Maybe the code for emit queue could be salvaged for the module thing > you talked about, please provide a bit more context about it. We talked offline, but for others. The idea here is when we have split BTF of a kernel module, we'd like to be able to dump it just like we do it for vmlinux BTF. But for kernel module we'd like to get <module>.h which would include only types defined in kernel module, skipping types that should be in base BTF (and thus come from vmlinux.h). The idea is that in practice you'd have something like: #include <vmlinux.h> #include <module1.h> #include <module2.h> and that will work together and won't conflict with vmlinux.h. > > Thanks, > Eduard
