Re: [RFC bpf-next 0/3] bpf: handle 0-sized structs properly

[Tony Ambardar <tony.ambardar@gmail.com>]

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@oracle.com> 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@oracle.com> 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?

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
 
[...]