Re: FYI: CI regression on big-endian arch (s390) after recent pahole changes

[Alan Maguire <alan.maguire@oracle.com>]

On 30/08/2024 23:20, Andrii Nakryiko wrote:
> On Fri, Aug 30, 2024 at 1:49 PM Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
>>
>> On Fri, Aug 30, 2024 at 08:56:08AM -0700, Andrii Nakryiko wrote:
>>> On Fri, Aug 30, 2024 at 6:19 AM Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>>>> On Fri, Aug 30, 2024 at 11:05:30AM +0100, Alan Maguire wrote:
>>>>> Arnaldo: apologies but I think we'll either need to back out the
>>>>> distilled stuff for 1.28 or have a new libbpf resync that captures the
>>>>> fixes for endian issues once they land. Let me know what works best for
>>>>> you. Thanks!
>>>>
>>>> It was useful, we got it tested more widely and caught this one.
>>>>
>>>> Andrii, what do you think? Can we get a 1.5.1 with this soon so that we
>>>> do a resying in pahole and then release 1.28?
>>>
>>> Did you mean 1.4.6? We haven't released v1.5 just yet.
>>>
>>> But yes, I'm going to cut a new set of bugfix releases to libbpf
>>> anyways, there is one more skeleton-related fix I have to backport.
>>>
>>> So I'll try to review, land, and backport the fix ASAP.
>>
>> Well, Alan sent patches updating libbpf to 1.5.0, so I misunderstood, I
>> think he meant what is to become 1.5.0, so even better, I think its just
>> a matter of updating the submodule sha:
>>
>> ⬢[acme@toolbox pahole]$ git show b6def578aa4a631f870568e13bfd647312718e7f
>> commit b6def578aa4a631f870568e13bfd647312718e7f
>> Author: Alan Maguire <alan.maguire@oracle.com>
>> Date:   Mon Jul 29 12:13:16 2024 +0100
>>
>>     pahole: Sync with libbpf-1.5
>>
>>     This will pull in BTF support for distilled base BTF.
>>
>>     Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
>>     Cc: Alexei Starovoitov <ast@kernel.org>
>>     Cc: Andrii Nakryiko <andrii@kernel.org>
>>     Cc: Eduard Zingerman <eddyz87@gmail.com>
>>     Cc: Jiri Olsa <jolsa@kernel.org>
>>     Cc: bpf@vger.kernel.org
>>     Cc: dwarves@vger.kernel.org
>>     Link: https://lore.kernel.org/r/20240729111317.140816-2-alan.maguire@oracle.com
>>     Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>>
>> diff --git a/lib/bpf b/lib/bpf
>> index 6597330c45d18538..686f600bca59e107 160000
>> --- a/lib/bpf
>> +++ b/lib/bpf
>> @@ -1 +1 @@
>> -Subproject commit 6597330c45d185381900037f0130712cd326ae59
>> +Subproject commit 686f600bca59e107af4040d0838ca2b02c14ff50
>> ⬢[acme@toolbox pahole]$
>>
>> Right?
> 
> Yes, and I'm doing another Github sync today.
> 
> Separate question, I think pahole supports the shared library version
> of libbpf, as an option, is that right? How do you guys handle missing
> APIs for distilled BTF in such a case?
>

Good question - at present the distill-related code is conditionally
compiled if LIBBPF_MAJOR_VERSION >=1 and LIBBF_MINOR_VERSION >= 5; so if
an older shared library libbpf+headers is used, the btf_feature is
simply ignored as if we didn't know about it. See [1] for the relevant
code in btf_encoder.c. This problem doesn't arise if we're using the
synced libbpf.

There might be a better way to handle this, but I think that's enough to
ensure we avoid compilation failures at least.

[1]
https://github.com/acmel/dwarves/blob/fd14dc67cb6aaead553074afb4a1ddad10209892/btf_encoder.c#L1766

>>
>> - Arnaldo