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

[Arnaldo Carvalho de Melo <acme@kernel.org>]

On Mon, Sep 02, 2024 at 03:59:26PM +0100, Alan Maguire wrote:
> 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!

I dropped mine and picked yours :-)

Thanks!

- Arnaldo
 
> 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