On Thu, May 15, 2025 at 1:02 AM Tony Ambardar <tony.ambardar@xxxxxxxxx> wrote: > > On Wed, May 14, 2025 at 09:22:00AM -0700, Andrii Nakryiko wrote: > > On Wed, May 14, 2025 at 3:31 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > > > > > On 12/05/2025 10:17, Tony Ambardar wrote: > > > > On Fri, May 09, 2025 at 11:40:47AM -0700, Andrii Nakryiko wrote: > > > >> On Thu, May 8, 2025 at 6:22 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > [...] > > Hi Alan, Andrii, > > > > > Given pahole (and my related patch) assume pass-by-value for well-sized > > > > structs, I'd like to see this too. But while the pahole patch works on > > > > 64/32-bit archs, I noticed from patch #1 that e.g. ___bpf_treg_cnt() > > > > seems to hard-code a 64-bit register size. Perhaps we can fix that too? > > > > > > > > > > So I think your concern is the assumptions > > > > > > > > > __builtin_choose_expr(sizeof(t) == 8, 1, \ > > > __builtin_choose_expr(sizeof(t) == 16, 2, \ > > > > > > ? We may need arch-specific macros that specify register size that we > > > can use here, or is there a better way? > > > > we know the target architecture, so this shouldn't be hard to define > > the word size accordingly and use that here? > > > > Well, I'm now unsure if this is a problem after reading the code more > closely. The ctx is a u64 array and the PROG2-related macros process ctx > elems within the BPF VM using 64-bit regs. Does this mean the macro/union > magic all works OK then? I'd think that it's still a problem, because on 32-bit architecture if argument is 8 byte long, we'll use 2 registers, and each register will get their ctx[i] and ctx[i + 1] slot, so we need to take into account 32-bit vs 64-bit distinction when calculating how many ctx[] slots we need to use/skip. > > Unfortunately, I cannot test a 32-bit host easily since JIT trampoline > support is still a WIP in my arm32 test setup. But perhaps someone can > share tracing experience with ppc32 JIT, which supports trampoline? > > Thanks, > Tony > > [...]
