On 31/08/2024 00:30, Andrii Nakryiko wrote: > On Fri, Aug 30, 2024 at 3:34 PM Alan Maguire <alan.maguire@xxxxxxxxxx> 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: >>>>> On Fri, Aug 30, 2024 at 6:19 AM Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> 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@xxxxxxxxxx> >>>> 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@xxxxxxxxxx> >>>> Cc: Alexei Starovoitov <ast@xxxxxxxxxx> >>>> Cc: Andrii Nakryiko <andrii@xxxxxxxxxx> >>>> Cc: Eduard Zingerman <eddyz87@xxxxxxxxx> >>>> Cc: Jiri Olsa <jolsa@xxxxxxxxxx> >>>> Cc: bpf@xxxxxxxxxxxxxxx >>>> Cc: dwarves@xxxxxxxxxxxxxxx >>>> Link: https://lore.kernel.org/r/20240729111317.140816-2-alan.maguire@xxxxxxxxxx >>>> Signed-off-by: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> >>>> >>>> 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
