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

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

On 02/09/2024 15:08, Arnaldo Carvalho de Melo wrote:
> On Fri, Aug 30, 2024 at 11:34:40PM +0100, Alan Maguire 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:
>>>> +++ b/lib/bpf
>>>> @@ -1 +1 @@
>>>> -Subproject commit 6597330c45d185381900037f0130712cd326ae59
>>>> +Subproject commit 686f600bca59e107af4040d0838ca2b02c14ff50
>>>> ⬢[acme@toolbox pahole]$
> 
>>>> Right?
> 
>>> Yes, and I'm doing another Github sync today.
> 
> So, I just commited this locally:
> 
> ⬢[acme@toolbox pahole]$ git show
> commit 5fd558301891d1c0456fcae79798a789b499c1f9 (HEAD -> master)
> Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> Date:   Mon Sep 2 11:05:06 2024 -0300
> 
>     libbpf: Sync with master, i.e. what will become 1.5.0
>     
>     To pick this distilled BPF fix:
>     
>       fe28fae57a9463fbf ("libbpf: Ensure new BTF objects inherit input endianness")
>     
>     Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> 
> diff --git a/lib/bpf b/lib/bpf
> index 686f600bca59e107..caa17bdcbfc58e68 160000
> --- a/lib/bpf
> +++ b/lib/bpf
> @@ -1 +1 @@
> -Subproject commit 686f600bca59e107af4040d0838ca2b02c14ff50
> +Subproject commit caa17bdcbfc58e68eaf4d017c058e6577606bf56
> ⬢[acme@toolbox pahole]$
> 
> Ack?
>

Acked-by: Alan Maguire <alan.maguire@oracle.com>

My patch for the same change crossed with your email [1], just ignore
it. Thanks!

Alan

[1]
https://lore.kernel.org/dwarves/20240902141043.177815-1-alan.maguire@oracle.com/T/#u

>>> 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.
> 
> I guess this is good enough,
> 
> - Arnaldo
>  
>> [1]
>> https://github.com/acmel/dwarves/blob/fd14dc67cb6aaead553074afb4a1ddad10209892/btf_encoder.c#L1766