<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/tools/bpf/bpftool/Makefile, branch v6.2.2</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.2.2</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.2.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-12-22T19:09:43+00:00</updated>
<entry>
<title>bpftool: Fix linkage with statically built libllvm</title>
<updated>2022-12-22T19:09:43+00:00</updated>
<author>
<name>Anton Protopopov</name>
<email>aspsk@isovalent.com</email>
</author>
<published>2022-12-22T10:26:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=55171f2930be98c8a49991435cdf3a8b574353b6'/>
<id>urn:sha1:55171f2930be98c8a49991435cdf3a8b574353b6</id>
<content type='text'>
Since the commit eb9d1acf634b ("bpftool: Add LLVM as default library for
disassembling JIT-ed programs") we might link the bpftool program with the
libllvm library. This works fine when a shared libllvm library is available,
but fails if we want to link bpftool with a statically built LLVM:

  [...]
  /usr/bin/ld: /usr/local/lib/libLLVMSupport.a(CrashRecoveryContext.cpp.o): in function `llvm::CrashRecoveryContextCleanup::~CrashRecoveryContextCleanup()':
  CrashRecoveryContext.cpp:(.text._ZN4llvm27CrashRecoveryContextCleanupD0Ev+0x17): undefined reference to `operator delete(void*, unsigned long)'
  /usr/bin/ld: /usr/local/lib/libLLVMSupport.a(CrashRecoveryContext.cpp.o): in function `llvm::CrashRecoveryContext::~CrashRecoveryContext()':
  CrashRecoveryContext.cpp:(.text._ZN4llvm20CrashRecoveryContextD2Ev+0xc8): undefined reference to `operator delete(void*, unsigned long)'
  [...]

So in the case of static libllvm we need to explicitly link bpftool with
required libraries, namely, libstdc++ and those provided by the `llvm-config
--system-libs` command. We can distinguish between the shared and static cases
by using the `llvm-config --shared-mode` command.

Fixes: eb9d1acf634b ("bpftool: Add LLVM as default library for disassembling JIT-ed programs")
Signed-off-by: Anton Protopopov &lt;aspsk@isovalent.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Stanislav Fomichev &lt;sdf@google.com&gt;
Link: https://lore.kernel.org/bpf/20221222102627.1643709-1-aspsk@isovalent.com
</content>
</entry>
<entry>
<title>bpftool: Add LLVM as default library for disassembling JIT-ed programs</title>
<updated>2022-10-25T17:11:56+00:00</updated>
<author>
<name>Quentin Monnet</name>
<email>quentin@isovalent.com</email>
</author>
<published>2022-10-25T15:03:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eb9d1acf634baf6401dfb4f67dc895290713a357'/>
<id>urn:sha1:eb9d1acf634baf6401dfb4f67dc895290713a357</id>
<content type='text'>
To disassemble instructions for JIT-ed programs, bpftool has relied on
the libbfd library. This has been problematic in the past: libbfd's
interface is not meant to be stable and has changed several times. For
building bpftool, we have to detect how the libbfd version on the system
behaves, which is why we have to handle features disassembler-four-args
and disassembler-init-styled in the Makefile. When it comes to shipping
bpftool, this has also caused issues with several distribution
maintainers unwilling to support the feature (see for example Debian's
page for binutils-dev, which ships libbfd: "Note that building Debian
packages which depend on the shared libbfd is Not Allowed." [0]).

For these reasons, we add support for LLVM as an alternative to libbfd
for disassembling instructions of JIT-ed programs. Thanks to the
preparation work in the previous commits, it's easy to add the library
by passing the relevant compilation options in the Makefile, and by
adding the functions for setting up the LLVM disassembler in file
jit_disasm.c.

The LLVM disassembler requires the LLVM development package (usually
llvm-dev or llvm-devel).

The expectation is that the interface for this disassembler will be more
stable. There is a note in LLVM's Developer Policy [1] stating that the
stability for the C API is "best effort" and not guaranteed, but at
least there is some effort to keep compatibility when possible (which
hasn't really been the case for libbfd so far). Furthermore, the Debian
page for the related LLVM package does not caution against linking to
the lib, as binutils-dev page does.

Naturally, the display of disassembled instructions comes with a few
minor differences. Here is a sample output with libbfd (already
supported before this patch):

    # bpftool prog dump jited id 56
    bpf_prog_6deef7357e7b4530:
       0:   nopl   0x0(%rax,%rax,1)
       5:   xchg   %ax,%ax
       7:   push   %rbp
       8:   mov    %rsp,%rbp
       b:   push   %rbx
       c:   push   %r13
       e:   push   %r14
      10:   mov    %rdi,%rbx
      13:   movzwq 0xb4(%rbx),%r13
      1b:   xor    %r14d,%r14d
      1e:   or     $0x2,%r14d
      22:   mov    $0x1,%eax
      27:   cmp    $0x2,%r14
      2b:   jne    0x000000000000002f
      2d:   xor    %eax,%eax
      2f:   pop    %r14
      31:   pop    %r13
      33:   pop    %rbx
      34:   leave
      35:   ret

LLVM supports several variants that we could set when initialising the
disassembler, for example with:

    LLVMSetDisasmOptions(*ctx,
                         LLVMDisassembler_Option_AsmPrinterVariant);

but the default printer is used for now. Here is the output with LLVM:

    # bpftool prog dump jited id 56
    bpf_prog_6deef7357e7b4530:
       0:   nopl    (%rax,%rax)
       5:   nop
       7:   pushq   %rbp
       8:   movq    %rsp, %rbp
       b:   pushq   %rbx
       c:   pushq   %r13
       e:   pushq   %r14
      10:   movq    %rdi, %rbx
      13:   movzwq  180(%rbx), %r13
      1b:   xorl    %r14d, %r14d
      1e:   orl     $2, %r14d
      22:   movl    $1, %eax
      27:   cmpq    $2, %r14
      2b:   jne     0x2f
      2d:   xorl    %eax, %eax
      2f:   popq    %r14
      31:   popq    %r13
      33:   popq    %rbx
      34:   leave
      35:   retq

The LLVM disassembler comes as the default choice, with libbfd as a
fall-back.

Of course, we could replace libbfd entirely and avoid supporting two
different libraries. One reason for keeping libbfd is that, right now,
it works well, we have all we need in terms of features detection in the
Makefile, so it provides a fallback for disassembling JIT-ed programs if
libbfd is installed but LLVM is not. The other motivation is that libbfd
supports nfp instruction for Netronome's SmartNICs and can be used to
disassemble offloaded programs, something that LLVM cannot do. If
libbfd's interface breaks again in the future, we might reconsider
keeping support for it.

[0] https://packages.debian.org/buster/binutils-dev
[1] https://llvm.org/docs/DeveloperPolicy.html#c-api-changes

Signed-off-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Tested-by: Niklas Söderlund &lt;niklas.soderlund@corigine.com&gt;
Acked-by: Yonghong Song &lt;yhs@fb.com&gt;
Link: https://lore.kernel.org/r/20221025150329.97371-7-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpftool: Group libbfd defs in Makefile, only pass them if we use libbfd</title>
<updated>2022-10-25T17:11:56+00:00</updated>
<author>
<name>Quentin Monnet</name>
<email>quentin@isovalent.com</email>
</author>
<published>2022-10-25T15:03:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2ea4d86a5093defcb2fc49799184ede178e64d36'/>
<id>urn:sha1:2ea4d86a5093defcb2fc49799184ede178e64d36</id>
<content type='text'>
Bpftool uses libbfd for disassembling JIT-ed programs. But the feature
is optional, and the tool can be compiled without libbfd support. The
Makefile sets the relevant variables accordingly. It also sets variables
related to libbfd's interface, given that it has changed over time.

Group all those libbfd-related definitions so that it's easier to
understand what we are testing for, and only use variables related to
libbfd's interface if we need libbfd in the first place.

In addition to make the Makefile clearer, grouping the definitions
related to disassembling JIT-ed programs will help support alternatives
to libbfd.

Signed-off-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Tested-by: Niklas Söderlund &lt;niklas.soderlund@corigine.com&gt;
Acked-by: Song Liu &lt;song@kernel.org&gt;
Link: https://lore.kernel.org/r/20221025150329.97371-5-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpftool: Split FEATURE_TESTS/FEATURE_DISPLAY definitions in Makefile</title>
<updated>2022-10-25T17:11:56+00:00</updated>
<author>
<name>Quentin Monnet</name>
<email>quentin@isovalent.com</email>
</author>
<published>2022-10-25T15:03:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=108326d6fa6c04e1473886fd662981792fc708a2'/>
<id>urn:sha1:108326d6fa6c04e1473886fd662981792fc708a2</id>
<content type='text'>
Make FEATURE_TESTS and FEATURE_DISPLAY easier to read and less likely to
be subject to conflicts on updates by having one feature per line.

Suggested-by: Andres Freund &lt;andres@anarazel.de&gt;
Signed-off-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Tested-by: Niklas Söderlund &lt;niklas.soderlund@corigine.com&gt;
Acked-by: Song Liu &lt;song@kernel.org&gt;
Link: https://lore.kernel.org/r/20221025150329.97371-4-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpftool: Complete libbfd feature detection</title>
<updated>2022-08-10T13:44:01+00:00</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2022-07-19T17:05:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=13e6f53a7692ac239241e6bc5c82c58c18c4f1ab'/>
<id>urn:sha1:13e6f53a7692ac239241e6bc5c82c58c18c4f1ab</id>
<content type='text'>
Commit 6e8ccb4f624a7 ("tools/bpf: properly account for libbfd variations")
sets the linking flags depending on which flavor of the libbfd feature was
detected.

However, the flavors except libbfd cannot be detected, as they are not in
the feature list.

Complete the list of features to detect by adding libbfd-liberty and
libbfd-liberty-z.

Committer notes:

Adjust conflict with with:

  1e1613f64cc8a09d ("tools bpftool: Don't display disassembler-four-args feature test")
  600b7b26c07a070d ("tools bpftool: Fix compilation error with new binutils")

Fixes: 6e8ccb4f624a73c5 ("tools/bpf: properly account for libbfd variations")
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Cc: Alexei Starovoitov &lt;ast@kernel.org&gt;
Cc: Andres Freund &lt;andres@anarazel.de&gt;
Cc: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Cc: bpf@vger.kernel.org
Cc: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: John Fastabend &lt;john.fastabend@gmail.com&gt;
Cc: KP Singh &lt;kpsingh@kernel.org&gt;
Cc: llvm@lists.linux.dev
Cc: Martin KaFai Lau &lt;martin.lau@linux.dev&gt;
Cc: Nathan Chancellor &lt;nathan@kernel.org&gt;
Cc: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Cc: Nick Terrell &lt;terrelln@fb.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: Song Liu &lt;song@kernel.org&gt;
Cc: Stanislav Fomichev &lt;sdf@google.com&gt;
Link: https://lore.kernel.org/r/20220719170555.2576993-2-roberto.sassu@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'perf-tools-for-v6.0-2022-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux</title>
<updated>2022-08-06T16:36:08+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-08-06T16:36:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=48a577dc1b09c1d35f2b8b37e7fa9a7169d50f5d'/>
<id>urn:sha1:48a577dc1b09c1d35f2b8b37e7fa9a7169d50f5d</id>
<content type='text'>
Pull perf tools updates from Arnaldo Carvalho de Melo:

 - Introduce 'perf lock contention' subtool, using new lock contention
   tracepoints and using BPF for in kernel aggregation and then
   userspace processing using the perf tooling infrastructure for
   resolving symbols, target specification, etc.

   Since the new lock contention tracepoints don't provide lock names,
   get up to 8 stack traces and display the first non-lock function
   symbol name as a caller:

    $ perf lock report -F acquired,contended,avg_wait,wait_total

                    Name   acquired  contended     avg wait    total wait

     update_blocked_a...         40         40      3.61 us     144.45 us
     kernfs_fop_open+...          5          5      3.64 us      18.18 us
      _nohz_idle_balance          3          3      2.65 us       7.95 us
     tick_do_update_j...          1          1      6.04 us       6.04 us
      ep_scan_ready_list          1          1      3.93 us       3.93 us

   Supports the usual 'perf record' + 'perf report' workflow as well as
   a BCC/bpftrace like mode where you start the tool and then press
   control+C to get results:

     $ sudo perf lock contention -b
    ^C
    contended   total wait     max wait     avg wait         type   caller

            42    192.67 us     13.64 us      4.59 us     spinlock   queue_work_on+0x20
            23     85.54 us     10.28 us      3.72 us     spinlock   worker_thread+0x14a
             6     13.92 us      6.51 us      2.32 us        mutex   kernfs_iop_permission+0x30
             3     11.59 us     10.04 us      3.86 us        mutex   kernfs_dop_revalidate+0x3c
             1      7.52 us      7.52 us      7.52 us     spinlock   kthread+0x115
             1      7.24 us      7.24 us      7.24 us     rwlock:W   sys_epoll_wait+0x148
             2      7.08 us      3.99 us      3.54 us     spinlock   delayed_work_timer_fn+0x1b
             1      6.41 us      6.41 us      6.41 us     spinlock   idle_balance+0xa06
             2      2.50 us      1.83 us      1.25 us        mutex   kernfs_iop_lookup+0x2f
             1      1.71 us      1.71 us      1.71 us        mutex   kernfs_iop_getattr+0x2c
    ...

 - Add new 'perf kwork' tool to trace time properties of kernel work
   (such as softirq, and workqueue), uses eBPF skeletons to collect info
   in kernel space, aggregating data that then gets processed by the
   userspace tool, e.g.:

    # perf kwork report

     Kwork Name      | Cpu | Total Runtime | Count | Max runtime | Max runtime start | Max runtime end |
    ----------------------------------------------------------------------------------------------------
     nvme0q5:130     | 004 |      1.101 ms |    49 |    0.051 ms |    26035.056403 s |  26035.056455 s |
     amdgpu:162      | 002 |      0.176 ms |     9 |    0.046 ms |    26035.268020 s |  26035.268066 s |
     nvme0q24:149    | 023 |      0.161 ms |    55 |    0.009 ms |    26035.655280 s |  26035.655288 s |
     nvme0q20:145    | 019 |      0.090 ms |    33 |    0.014 ms |    26035.939018 s |  26035.939032 s |
     nvme0q31:156    | 030 |      0.075 ms |    21 |    0.010 ms |    26035.052237 s |  26035.052247 s |
     nvme0q8:133     | 007 |      0.062 ms |    12 |    0.021 ms |    26035.416840 s |  26035.416861 s |
     nvme0q6:131     | 005 |      0.054 ms |    22 |    0.010 ms |    26035.199919 s |  26035.199929 s |
     nvme0q19:144    | 018 |      0.052 ms |    14 |    0.010 ms |    26035.110615 s |  26035.110625 s |
     nvme0q7:132     | 006 |      0.049 ms |    13 |    0.007 ms |    26035.125180 s |  26035.125187 s |
     nvme0q18:143    | 017 |      0.033 ms |    14 |    0.007 ms |    26035.169698 s |  26035.169705 s |
     nvme0q17:142    | 016 |      0.013 ms |     1 |    0.013 ms |    26035.565147 s |  26035.565160 s |
     enp5s0-rx-0:164 | 006 |      0.004 ms |     4 |    0.002 ms |    26035.928882 s |  26035.928884 s |
     enp5s0-tx-0:166 | 008 |      0.003 ms |     3 |    0.002 ms |    26035.870923 s |  26035.870925 s |
    --------------------------------------------------------------------------------------------------------

   See commit log messages for more examples with extra options to limit
   the events time window, etc.

 - Add support for new AMD IBS (Instruction Based Sampling) features:

   With the DataSrc extensions, the source of data can be decoded among:
     - Local L3 or other L1/L2 in CCX.
     - A peer cache in a near CCX.
     - Data returned from DRAM.
     - A peer cache in a far CCX.
     - DRAM address map with "long latency" bit set.
     - Data returned from MMIO/Config/PCI/APIC.
     - Extension Memory (S-Link, GenZ, etc - identified by the CS target
       and/or address map at DF's choice).
     - Peer Agent Memory.

 - Support hardware tracing with Intel PT on guest machines, combining
   the traces with the ones in the host machine.

 - Add a "-m" option to 'perf buildid-list' to show kernel and modules
   build-ids, to display all of the information needed to do external
   symbolization of kernel stack traces, such as those collected by
   bpf_get_stackid().

 - Add arch TSC frequency information to perf.data file headers.

 - Handle changes in the binutils disassembler function signatures in
   perf, bpftool and bpf_jit_disasm (Acked by the bpftool maintainer).

 - Fix building the perf perl binding with the newest gcc in distros
   such as fedora rawhide, where some new warnings were breaking the
   build as perf uses -Werror.

 - Add 'perf test' entry for branch stack sampling.

 - Add ARM SPE system wide 'perf test' entry.

 - Add user space counter reading tests to 'perf test'.

 - Build with python3 by default, if available.

 - Add python converter script for the vendor JSON event files.

 - Update vendor JSON files for most Intel cores.

 - Add vendor JSON File for Intel meteorlake.

 - Add Arm Cortex-A78C and X1C JSON vendor event files.

 - Add workaround to symbol address reading from ELF files without phdr,
   falling back to the previoous equation.

 - Convert legacy map definition to BTF-defined in the perf BPF script
   test.

 - Rework prologue generation code to stop using libbpf deprecated APIs.

 - Add default hybrid events for 'perf stat' on x86.

 - Add topdown metrics in the default 'perf stat' on the hybrid machines
   (big/little cores).

 - Prefer sampled CPU when exporting JSON in 'perf data convert'

 - Fix ('perf stat CSV output linter') and ("Check branch stack
   sampling") 'perf test' entries on s390.

* tag 'perf-tools-for-v6.0-2022-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (169 commits)
  perf stat: Refactor __run_perf_stat() common code
  perf lock: Print the number of lost entries for BPF
  perf lock: Add --map-nr-entries option
  perf lock: Introduce struct lock_contention
  perf scripting python: Do not build fail on deprecation warnings
  genelf: Use HAVE_LIBCRYPTO_SUPPORT, not the never defined HAVE_LIBCRYPTO
  perf build: Suppress openssl v3 deprecation warnings in libcrypto feature test
  perf parse-events: Break out tracepoint and printing
  perf parse-events: Don't #define YY_EXTRA_TYPE
  tools bpftool: Don't display disassembler-four-args feature test
  tools bpftool: Fix compilation error with new binutils
  tools bpf_jit_disasm: Don't display disassembler-four-args feature test
  tools bpf_jit_disasm: Fix compilation error with new binutils
  tools perf: Fix compilation error with new binutils
  tools include: add dis-asm-compat.h to handle version differences
  tools build: Don't display disassembler-four-args feature test
  tools build: Add feature test for init_disassemble_info API changes
  perf test: Add ARM SPE system wide test
  perf tools: Rework prologue generation code
  perf bpf: Convert legacy map definition to BTF-defined
  ...
</content>
</entry>
<entry>
<title>tools bpftool: Don't display disassembler-four-args feature test</title>
<updated>2022-08-01T18:34:05+00:00</updated>
<author>
<name>Andres Freund</name>
<email>andres@anarazel.de</email>
</author>
<published>2022-08-01T01:38:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1e1613f64cc8a09d7a60ad01450c3321ca4ad454'/>
<id>urn:sha1:1e1613f64cc8a09d7a60ad01450c3321ca4ad454</id>
<content type='text'>
The feature check does not seem important enough to display.

Requested-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Signed-off-by: Andres Freund &lt;andres@anarazel.de&gt;
Acked-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Cc: Alexei Starovoitov &lt;ast@kernel.org&gt;
Cc: Ben Hutchings &lt;benh@debian.org&gt;
Cc: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Cc: bpf@vger.kernel.org
Link: http://lore.kernel.org/lkml/20220622181918.ykrs5rsnmx3og4sv@alap3.anarazel.de
Link: https://lore.kernel.org/r/20220801013834.156015-9-andres@anarazel.de
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>tools bpftool: Fix compilation error with new binutils</title>
<updated>2022-08-01T18:32:46+00:00</updated>
<author>
<name>Andres Freund</name>
<email>andres@anarazel.de</email>
</author>
<published>2022-08-01T01:38:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=600b7b26c07a070d0153daa76b3806c1e52c9e00'/>
<id>urn:sha1:600b7b26c07a070d0153daa76b3806c1e52c9e00</id>
<content type='text'>
binutils changed the signature of init_disassemble_info(), which now causes
compilation to fail for tools/bpf/bpftool/jit_disasm.c, e.g. on debian
unstable.

Relevant binutils commit:

  https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=60a3da00bd5407f07

Wire up the feature test and switch to init_disassemble_info_compat(),
which were introduced in prior commits, fixing the compilation failure.

I verified that bpftool can still disassemble bpf programs, both with an
old and new dis-asm.h API. There are no output changes for plain and json
formats. When comparing the output from old binutils (2.35)
to new bintuils with the patch (upstream snapshot) there are a few output
differences, but they are unrelated to this patch. An example hunk is:

     2f:	pop    %r14
     31:	pop    %r13
     33:	pop    %rbx
  -  34:	leaveq
  -  35:	retq
  +  34:	leave
  +  35:	ret

Signed-off-by: Andres Freund &lt;andres@anarazel.de&gt;
Acked-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: Alexei Starovoitov &lt;ast@kernel.org&gt;
Cc: Ben Hutchings &lt;benh@debian.org&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Cc: bpf@vger.kernel.org
Link: http://lore.kernel.org/lkml/20220622181918.ykrs5rsnmx3og4sv@alap3.anarazel.de
Link: https://lore.kernel.org/r/20220801013834.156015-8-andres@anarazel.de
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>bpftool: Remove zlib feature test from Makefile</title>
<updated>2022-07-06T05:31:17+00:00</updated>
<author>
<name>Quentin Monnet</name>
<email>quentin@isovalent.com</email>
</author>
<published>2022-07-05T20:04:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=450a8dcb8c7f819431b09e5c1debbf0b6c2e824e'/>
<id>urn:sha1:450a8dcb8c7f819431b09e5c1debbf0b6c2e824e</id>
<content type='text'>
The feature test to detect the availability of zlib in bpftool's
Makefile does not bring much. The library is not optional: it may or may
not be required along libbfd for disassembling instructions, but in any
case it is necessary to build feature.o or even libbpf, on which bpftool
depends.

If we remove the feature test, we lose the nicely formatted error
message, but we get a compiler error about "zlib.h: No such file or
directory", which is equally informative. Let's get rid of the test.

Suggested-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Signed-off-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20220705200456.285943-1-quentin@isovalent.com
</content>
</entry>
<entry>
<title>bpftool: Fix bootstrapping during a cross compilation</title>
<updated>2022-06-09T12:01:21+00:00</updated>
<author>
<name>Shahab Vahedi</name>
<email>Shahab.Vahedi@synopsys.com</email>
</author>
<published>2022-06-08T14:29:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0b817059a8830b8bc3d50bb2402dea923cd89b01'/>
<id>urn:sha1:0b817059a8830b8bc3d50bb2402dea923cd89b01</id>
<content type='text'>
This change adjusts the Makefile to use "HOSTAR" as the archive tool
to keep the sanity of the build process for the bootstrap part in
check. For the rationale, please continue reading.

When cross compiling bpftool with buildroot, it leads to an invocation
like:

$ AR="/path/to/buildroot/host/bin/arc-linux-gcc-ar" \
  CC="/path/to/buildroot/host/bin/arc-linux-gcc"    \
  ...
  make

Which in return fails while building the bootstrap section:

----------------------------------8&lt;----------------------------------

  make: Entering directory '/src/bpftool-v6.7.0/src'
  ...                        libbfd: [ on  ]
  ...        disassembler-four-args: [ on  ]
  ...                          zlib: [ on  ]
  ...                        libcap: [ OFF ]
  ...               clang-bpf-co-re: [ on  ] &lt;-- triggers bootstrap

  .
  .
  .

    LINK     /src/bpftool-v6.7.0/src/bootstrap/bpftool
  /usr/bin/ld: /src/bpftool-v6.7.0/src/bootstrap/libbpf/libbpf.a:
               error adding symbols: archive has no index; run ranlib
               to add one
  collect2: error: ld returned 1 exit status
  make: *** [Makefile:211: /src/bpftool-v6.7.0/src/bootstrap/bpftool]
            Error 1
  make: *** Waiting for unfinished jobs....
    AR       /src/bpftool-v6.7.0/src/libbpf/libbpf.a
    make[1]: Leaving directory '/src/bpftool-v6.7.0/libbpf/src'
    make: Leaving directory '/src/bpftool-v6.7.0/src'

----------------------------------&gt;8----------------------------------

This occurs because setting "AR" confuses the build process for the
bootstrap section and it calls "arc-linux-gcc-ar" to create and index
"libbpf.a" instead of the host "ar".

Signed-off-by: Shahab Vahedi &lt;shahab@synopsys.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Reviewed-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: Jean-Philippe Brucker &lt;jean-philippe@linaro.org&gt;
Link: https://lore.kernel.org/bpf/8d297f0c-cfd0-ef6f-3970-6dddb3d9a87a@synopsys.com
</content>
</entry>
</feed>
