Hi Alexei,
On Thu Jun 5, 2025 at 6:09 PM CEST, Alexei Starovoitov wrote:
On Thu, Jun 5, 2025 at 12:35 AM Alexis Lothoré alexis.lothore@bootlin.com wrote:
Hi Ihor,
On Wed Jun 4, 2025 at 7:31 PM CEST, Ihor Solodrai wrote:
On 6/4/25 2:02 AM, Alexis Lothoré wrote:
[...]
Thanks for the details ! I have missed this possibility, as I have been assuming that DWARF info was exposing the needed info. I'll take a look at it, but if those attributes can not be represented by DWARF, I'll have to find another way of getting those packing/alignment modifications on data type (eg: re-use/share btf__align_of from libbpf, as suggested by Andrii, but it may not able to cover all cases).
Not sure all the trouble is worth it. I feel it's a corner case. Something we don't need to fix.
TBH I don't own any specific use case really needing this handling, so if it does not feel worth the trouble, I'm fine with not trying to support this. My effort is rather motivated by the goal of aligning the ARM64 features with other platform, and so of getting rid of tools/testing/selftests/bpf/DENYLIST.aarch64.
For the record, this effort also showed that the same kind of issue affects other platforms already supporting many args + structs passed by value ([1]) - structs alignment with specific alignment constraints are not specifically handled (eg: a struct with an __int128 as a top-level member, leading to a 16 byte alignment requirement) - packing and custom alignment is not handled
From there, I could do two different things: 1. do nothing, keep ARM64 as-is with the current version which has been recently merged: ARM64 then denies attachment to any function trying to pass a struct by value on stack. We keep the tracing_struct tests denied for ARM64. Other platforms still allow to attach such functions, but may be parsing wrongly arguments in those specific cases. 2. add the constraint applied on ARM64 (refusing attachment when structs are passed through stack) to other JIT compilers. Then update the tracing_struct test to ensure this specific case is properly denied on all platforms to avoid risking reading wrongly arguments passed through stack when structs or large types are involved.
I tend to think 2. is better, but let me know if you have a different opinion here.
Thanks,
Alexis