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

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

On 31/08/2024 00:30, Andrii Nakryiko wrote:
> On Fri, Aug 30, 2024 at 3:34 PM Alan Maguire <alan.maguire@oracle.com> wrote:
>>
>> 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.
> 
> Is it possible to compile against newer libbpf headers, but run with
> older shared library?
>

It would be possible alright; the most important case is package build
time versus package install time. IIRC rpmbuild will auto-detect the
version dependency (as long as libbpf is packaged too I think). We
probably don't want an explicit libbpf "Requires:" dependency in the
dwarves spec file since that wouldn't be needed for the static libbpf
library case.

> BTW, I've just synced the latest libbpf sources to Github ([0]), feel
> free to pull the latest submodule reference.
> 
>   [0] https://github.com/libbpf/libbpf/pull/848
> 

Great, thanks! I'll send a patch to update the sha from the dwarves side.

Alan