Re: [PATCH dwarves v2] dwarf_loader: Fix skipped encoding of function BTF on 32-bit systems

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

On Thu, May 08, 2025 at 02:24:57PM +0100, Alan Maguire wrote:
> On 02/05/2025 08:03, Tony Ambardar wrote:
> > I encountered an issue building BTF kernels for 32-bit armhf, where many
> > functions are missing in BTF data:
> > 
> >   LD      vmlinux
> >   BTFIDS  vmlinux
> > WARN: resolve_btfids: unresolved symbol vfs_truncate

[...]

> > 
> > Fixes: a53c58158b76 ("dwarf_loader: Mark functions that do not use expected registers for params")
> > Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
> 

Hello Alan,

> I've tried this on x86_64 and the issue of missing functions has
> disappeared; I get the exact same number of functions encoded. From a
> pahole perspective
> 
> Tested-by: Alan Maguire <alan.maguire@oracle.com>
> 

Thanks for reviewing the latest update and putting it through its paces.
I was noticing many small changes in my own testing so this is welcome
confirmation.

> However as mentioned previously I think we need to think a bit about how
> libbpf for example might accommodate such representations, as the
> implict assumption for fentry in BPF_PROG() is that the function call
> register conventions apply. BPF_PROG2() handles the struct case, but not
> the 0-sized struct case, and in fact there are checks in btf.c that also
> need to be fixed to enable verification once we have 0-sized struct
> argument support.
> 
> So in investigating this I've put together a short RFC series [1] that
> seems to do the job in
> 
> 1. fixing up the BPF_PROG2() handling of 0-sized structs.
> 2. fixing the verification failures with 0-sized parameters, carving out
> an exception for 0-sized structs.
> 3. testing the 0-sized struct case to ensure we get the correct data by
> adding a function with a 0-sized struct parameter to bpf_testmod and
> adding a tracing_struct test to verify the subsequent arguments are correct.
>

OK, I'll try looking at this for 32-bit armhf since I'm in the middle of
that, and comment in the RFC thread.

> In terms of cadence, I would propose that if the BPF folks are happy
> with the approach, we land this patch in pahole, then after that try to
> land the BPF changes. Does that work from your side? Thanks!
> 
> [1]
> https://lore.kernel.org/bpf/20250508132237.1817317-1-alan.maguire@oracle.com/
> 
> Alan
> 

Thanks,
Tony

[...]