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@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?
>
Acked-by: Alan Maguire <alan.maguire@xxxxxxxxxx>
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@xxxxxxxxxx/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
