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

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

Hi Alexis,

On Thu, May 08, 2025 at 11:38:06AM +0200, Alexis Lothoré wrote:
> Hello,
> 
> On Fri May 2, 2025 at 9:03 AM CEST, Tony Ambardar wrote:
> > I encountered an issue building BTF kernels for 32-bit armhf, where many
> > functions are missing in BTF data:
> 
> [...]
> 
> > Fixes: a53c58158b76 ("dwarf_loader: Mark functions that do not use expected registers for params")
> > Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>
> 
> I encountered some issues with pahole 1.30 when trying to generate BTF data
> for functions having some __int128 values ([1]), and have been redirected
> here by Tony. I gave a try to the patch below and confirm that it fixes my
> issue: BTF data is now properly generated for my target function, so:
> 
> Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com>
> 

Glad that resolved your issue, and thank you for the extra testing data
point.

> While at it, to follow-up on Alan's request for more testing, I did the
> following:
> - build kernel and bpf selftests with pahole 1.30, extract BTF raw data
>   with bpftool
> - repeat with pahole 1.30 + Tony's patch
> - I build my kernel for arm64, it is based on bpf-next_base and I use a
>   defconfig very close to the one used in BPF CI (so based on
>   tools/testing/selftests/bpf/config*)
> 

Nice! I notice bootlin has worked on several BPF testing contributions,
and was wondering if your build is some new standard buildroot/yocto
config tailored for BPF testing, and what archs it might support? Reason
for asking is I have a large stack of WIP patches for enabling use of
test_progs across 64/32-bit archs and cross-compilation, and I'm keen to
see other examples of configs, root images, etc. (especially for 32-bit)
At the moment I'm targeting 32-bit armhf support to make progress..

> I observe the following when comparing the resulting BTF data with/without
> Tony's patch:
> - There is no difference on vmlinux BTF data
> - For bpf_testmod.ko, there is a slight shift in the first BTF ID (first ID
>   is 46 with pristine pahole, 47 with patched pahole), which in turns makes
>   a lot of noise in the diff, but the actual diff seems to be about two new
>   BTF entries related to my custom function now being properly detected
>   (BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO)
> 

Right, I noticed the same skew and it does make checking equivalence more
complicated.

> Alexis
> 
> [1] https://lore.kernel.org/bpf/D9Q73OTLEOU4.LNAO9K4POETM@bootlin.com/
> 
> -- 
> Alexis Lothoré, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 
Thanks again,
Tony