Hi all, a simpler version of this series has been merged, and so I am now taking a look at the issue I have put aside in the merged version: dealing with more specific data layout for arguments passed on stack. For example, a function can pass small structs on stack, but this need special care when generating the corresponding bpf trampolines. Those structs have specific alignment specified by the target ABI, but it can also be altered with attributes packing the structure or modifying the alignment.
Some platforms already support structs on stack (see tracing_struct_many_args test), but as discussed earlier, those may suffer from the same kind of issue mentioned above.
On Wed Apr 23, 2025 at 9:24 PM CEST, Alexis Lothoré wrote:
Hi Andrii,
On Wed Apr 23, 2025 at 7:15 PM CEST, Andrii Nakryiko wrote:
On Thu, Apr 17, 2025 at 12:14 AM Alexis Lothoré alexis.lothore@bootlin.com wrote:
Hi Andrii,
On Wed Apr 16, 2025 at 11:24 PM CEST, Andrii Nakryiko wrote:
[...]
I'd suggest looking at btf__align_of() in libbpf (tools/lib/bpf/btf.c) to see how we calculate alignment there. It seems to work decently enough. It won't cover any arch-specific extra rules like double needing 16-byte alignment (I vaguely remember something like that for some architectures, but I might be misremembering), or anything similar. It also won't detect (I don't think it's possible without DWARF) artificially increased alignment with attribute((aligned(N))).
Thanks for the pointer, I'll take a look at it. The more we discuss this series, the less member size sounds relevant for what I'm trying to achieve here.
Following Xu's comments, I have been thinking about how I could detect the custom alignments and packing on structures, and I was wondering if I could somehow benefit from __attribute__ encoding in BTF info ([1]). But following your hint, I also see some btf_is_struct_packed() in tools/lib/bpf/btf_dump.c that could help. I'll dig this further and see if I can manage to make something work with all of this.
Andrii's comment above illustrates well my current issue: when functions pass arguments on stack, we are missing info for some of them to correctly build trampolines, especially for struct, which can have attributes like __attribute__((packed)) or __attribute__((align(x))). [1] seems to be a recent solution implemented for BTF to cover this need. IIUC it encodes any arbitratry attribute affecting a data type or function, so if I have some struct like this one in my kernel or a module:
struct foo { short b int a; } __packed;
I would expect the corresponding BTF data to have some BTF_KIND_DECL_TAG describing the "packed" attribute for the corresponding structure, but I fail to find any of those when running:
$ bpftool btf dump file vmlinux format raw
In there I see some DECL_TAG but those are mostly 'bpf_kfunc', I see not arbitrary attribute like 'packed' or 'aligned(x)'.
What I really need to do in the end is to be able to parse those alignments attributes info in the kernel at runtime when generating trampolines, but I hoped to be able to see them with bpftool first to validate the concept.
I started taking a look further at this and stumbled upon [2] in which Alan gives many more details about the feature, so I did the following checks: - kernel version 6.15.0-rc4 from bpf-next_base: it contains the updated Makefile.btf calling pahole with `--btf_features=attributes` - pahole v1.30 $ pahole --supported_btf_features encode_force,var,float,decl_tag,type_tag,enum64,optimized_func,consistent_func,decl_tag_kfuncs,reproducible_build,distilled_base,global_var,attributes This pahole comes from my distro pkg manager, but I have also done the same test with a freshly built pahole, while taking care of pulling the libbpf submodule. - bpftool v7.6.0 bpftool v7.6.0 using libbpf v1.6 features: llvm, skeletons
Could I be missing something obvious ? Or did I misunderstand the actual attribute encoding feature ?
Thanks,
Alexis
[1] https://lore.kernel.org/bpf/20250130201239.1429648-1-ihor.solodrai@linux.dev... [2] https://lore.kernel.org/all/CA+icZUW31vpS=R3zM6G4FMkzuiQovqtd+e-8ihwsK_A-QtS...