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@xxxxxxxxx>
>
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@xxxxxxxxxx>
>
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@xxxxxxxxxx/
>
> Alan
>
Thanks,
Tony
[...]
