On 26/06/2024 11:51, Totoro W wrote: > Alan Maguire <alan.maguire@xxxxxxxxxx> 于2024年6月26日周三 18:19写道： >> >> On 26/06/2024 08:29, Totoro W wrote: >>> Hi folks, >>> >>> This is my first time to ask questions in this mailing list. I'm the >>> author of https://github.com/tw4452852/zbpf which is a framework to >>> write BPF programs with Zig toolchain. >>> During the development, as the BTF is totally generated by the Zig >>> toolchain, some naming conventions will make the BTF verifier refuse >>> to load. >>> Right now I have to patch the libbpf to do some fixup before loading >>> into the kernel >>> (https://github.com/tw4452852/libbpf_zig/blob/main/0001-temporary-WA-for-invalid-BTF-info-generated-by-Zig.patch). >>> Even though this just work-around the issue, I'm still curious about >>> the current naming sanitation, I want to know some background about >>> it. >>> If possible, could we relax this to accept more languages (like Zig) >>> to write BPF programs? Thanks in advance. >>> >>> For reference, here the BTF generated by Zig for this program >>> (https://github.com/tw4452852/zbpf/blob/main/samples/perf_event.zig) >>> >>> [1] PTR '*[4]u8' type_id=3 >> >> The problem here as Eduard mentioned is that the zig compiler appears to >> be generating unneeded names for pointers, and then you're working >> around this in zbpf, is that right? > Yes, you're right, I kind of workaround this issue in zbpf. > >> It's not clear to me what that >> pointer name adds - I suspect it's saying it's a pointer to an array of >> 4 u8s, but we get that from the fact it's a PTR to type_id 3 - an ARRAY >> with element type 'u8' (type id 2) and nr_elems=4, no name is needed. So >> the name doesn't add any information it seems; or at least the info the >> name provides can be reconstructed from the BTF without having the name. > Your guess is right. > >> >> So the root problem here appears to be the zig compiler's BTF >> generation. If there are some language constraints that require some >> sort of name annotation for pointers, couldn't that be done via BTF type >> tags or via some other compatible mechanism? >> >> So I think we need to understand whether the BTF incompatibilities arise >> due to genuine language features or if they are the result of >> incorrectly-generated BTF during zig compilation. I dug around a bit in >> the zig github repo but could only find BTF parsing code, not code for >> BTF generation. Finding where the BTF is generated in the zig toolchain >> and understanding why it is generating names for pointers is the first >> step here I think. > Currently, for the BPF platform, Zig uses LLVM as backend. So the BTF > generation is done > by LLVM (https://github.com/llvm/llvm-project/blob/37eb9c9632fb5e82827d1a0559f2279e9a9f1969/llvm/lib/Target/BPF/BTFDebug.cpp) > with debug meta information provided by the Zig toolchain > (https://github.com/ziglang/zig/blob/master/src/codegen/llvm.zig) > I suspect the problem is somewhere around here: diff --git a/src/codegen/llvm.zig b/src/codegen/llvm.zig index 1e29d2cbe5..9ffcc97393 100644 --- a/src/codegen/llvm.zig +++ b/src/codegen/llvm.zig @@ -2201,7 +2201,7 @@ pub const Object = struct { defer gpa.free(name); const debug_ptr_type = try o.builder.debugPointerType( - try o.builder.metadataString(name), + .none, // Name .none, // File .none, // Scope 0, // Line That metadataString makes its way into debug info and then BTF. No idea if the above works as a fix but I'd start somewhere around there with the zig debug info generation and see if adding an empty name helps. Alan
