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@xxxxxxxxx>
>
> 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@xxxxxxxxxxx>
>
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@xxxxxxxxxxx/
>
> --
> Alexis Lothoré, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
Thanks again,
Tony
