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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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@xxxxxxxxxx>
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@xxxxxxxxxx>

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




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux