<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/tools/perf/Makefile.config, branch v6.1.168</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-06-27T10:07:14+00:00</updated>
<entry>
<title>perf build: Warn when libdebuginfod devel files are not available</title>
<updated>2025-06-27T10:07:14+00:00</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2025-04-08T14:37:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eff345ff209a83d40d56adcb6518f0cbaa1481b6'/>
<id>urn:sha1:eff345ff209a83d40d56adcb6518f0cbaa1481b6</id>
<content type='text'>
[ Upstream commit 4fce4b91fd1aabb326c46e237eb4b19ab72598f8 ]

While working on 'perf version --build-options' I noticed that:

  $ perf version --build-options
  perf version 6.15.rc1.g312a07a00d31
                   aio: [ on  ]  # HAVE_AIO_SUPPORT
                   bpf: [ on  ]  # HAVE_LIBBPF_SUPPORT
         bpf_skeletons: [ on  ]  # HAVE_BPF_SKEL
            debuginfod: [ OFF ]  # HAVE_DEBUGINFOD_SUPPORT
  &lt;SNIP&gt;

And looking at tools/perf/Makefile.config I also noticed that it is not
opt-in, meaning we will attempt to build with it in all normal cases.

So add the usual warning at build time to let the user know that
something recommended is missing, now we see:

  Makefile.config:563: No elfutils/debuginfod.h found, no debuginfo server support, please install elfutils-debuginfod-client-devel or equivalent

And after following the recommendation:

  $ perf check feature debuginfod
            debuginfod: [ on  ]  # HAVE_DEBUGINFOD_SUPPORT
  $ ldd ~/bin/perf | grep debuginfo
	libdebuginfod.so.1 =&gt; /lib64/libdebuginfod.so.1 (0x00007fee5cf5f000)
  $

With this feature on several perf tools will fetch what is needed and
not require all the contents of the debuginfo packages, for instance:

  # rpm -qa | grep kernel-debuginfo
  # pahole --running_kernel_vmlinux
  pahole: couldn't find a vmlinux that matches the running kernel
  HINT: Maybe you're inside a container or missing a debuginfo package?
  #
  # perf trace -e open* perf probe --vars icmp_rcv
      0.000 ( 0.005 ms): perf/97391 openat(dfd: CWD, filename: "/etc/ld.so.cache", flags: RDONLY|CLOEXEC) = 3
      0.014 ( 0.004 ms): perf/97391 openat(dfd: CWD, filename: "/lib64/libm.so.6", flags: RDONLY|CLOEXEC) = 3
  &lt;SNIP&gt;
  32130.100 ( 0.008 ms): perf/97391 openat(dfd: CWD, filename: "/root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo") = 3
  &lt;SNIP&gt;
  Available variables at icmp_rcv
        @&lt;icmp_rcv+0&gt;
                struct sk_buff* skb
  &lt;SNIP&gt;
  #
  # pahole --running_kernel_vmlinux
  /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo
  # file /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo
  /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=aa3c82b4a13f9c0e0301bebb20fe958c4db6f362, with debug_info, not stripped
  # ls -la /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo
  -r--------. 1 root root 475401512 Mar 27 21:00 /root/.cache/debuginfod_client/aa3c82b4a13f9c0e0301bebb20fe958c4db6f362/debuginfo
  #

Then, cached:

  # perf stat --null perf probe --vars icmp_rcv
  Available variables at icmp_rcv
        @&lt;icmp_rcv+0&gt;
                struct sk_buff* skb

   Performance counter stats for 'perf probe --vars icmp_rcv':

       0.671389041 seconds time elapsed

       0.519176000 seconds user
       0.150860000 seconds sys

Fixes: c7a14fdcb3fa7736 ("perf build-ids: Fall back to debuginfod query if debuginfo not found")
Tested-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Dmitriy Vyukov &lt;dvyukov@google.com&gt;
Cc: Howard Chu &lt;howardchu95@gmail.com&gt;
Cc: Ian Rogers &lt;irogers@google.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Kan Liang &lt;kan.liang@linux.intel.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Frank Ch. Eigler &lt;fche@redhat.com&gt;
Link: https://lore.kernel.org/r/Z_dkNDj9EPFwPqq1@gmail.com
[ Folded patch from Ingo to have the debian/ubuntu devel package added build warning message ]
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf build: Fix library not found error when using CSLIBS</title>
<updated>2023-07-27T06:50:39+00:00</updated>
<author>
<name>James Clark</name>
<email>james.clark@arm.com</email>
</author>
<published>2023-07-07T15:45:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=08bdd70974a8228b61a7d0f3f770d27832287aab'/>
<id>urn:sha1:08bdd70974a8228b61a7d0f3f770d27832287aab</id>
<content type='text'>
[ Upstream commit 1feece2780ac2f8de45177fe53979726cee4b3d1 ]

-L only specifies the search path for libraries directly provided in the
link line with -l. Because -lopencsd isn't specified, it's only linked
because it's a dependency of -lopencsd_c_api. Dependencies like this are
resolved using the default system search paths or -rpath-link=... rather
than -L. This means that compilation only works if OpenCSD is installed
to the system rather than provided with the CSLIBS (-L) option.

This could be fixed by adding -Wl,-rpath-link=$(CSLIBS) but that is less
conventional than just adding -lopencsd to the link line so that it uses
-L. -lopencsd seems to have been removed in commit ed17b1914978eddb
("perf tools: Drop requirement for libstdc++.so for libopencsd check")
because it was thought that there was a chance compilation would work
even if it didn't exist, but I think that only applies to libstdc++ so
there is no harm to add it back. libopencsd.so and libopencsd_c_api.so
would always exist together.

Testing
=======

The following scenarios now all work:

 * Cross build with OpenCSD installed
 * Cross build using CSLIBS=...
 * Native build with OpenCSD installed
 * Native build using CSLIBS=...
 * Static cross build with OpenCSD installed
 * Static cross build with CSLIBS=...

Committer testing:

  ⬢[acme@toolbox perf-tools]$ alias m
  alias m='make -k BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools -C tools/perf install-bin &amp;&amp; git status &amp;&amp; perf test python ;  perf record -o /dev/null sleep 0.01 ; perf stat --null sleep 0.01'
  ⬢[acme@toolbox perf-tools]$ ldd ~/bin/perf | grep csd
  	libopencsd_c_api.so.1 =&gt; /lib64/libopencsd_c_api.so.1 (0x00007fd49c44e000)
  	libopencsd.so.1 =&gt; /lib64/libopencsd.so.1 (0x00007fd49bd56000)
  ⬢[acme@toolbox perf-tools]$ cat /etc/redhat-release
  Fedora release 36 (Thirty Six)
  ⬢[acme@toolbox perf-tools]$

Fixes: ed17b1914978eddb ("perf tools: Drop requirement for libstdc++.so for libopencsd check")
Reported-by: Radhey Shyam Pandey &lt;radhey.shyam.pandey@amd.com&gt;
Signed-off-by: James Clark &lt;james.clark@arm.com&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Tested-by: Radhey Shyam Pandey &lt;radhey.shyam.pandey@amd.com&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Ian Rogers &lt;irogers@google.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Uwe Kleine-König &lt;uwe@kleine-koenig.org&gt;
Cc: coresight@lists.linaro.org
Closes: https://lore.kernel.org/linux-arm-kernel/56905d7a-a91e-883a-b707-9d5f686ba5f1@arm.com/
Link: https://lore.kernel.org/all/36cc4dc6-bf4b-1093-1c0a-876e368af183@kleine-koenig.org/
Link: https://lore.kernel.org/r/20230707154546.456720-1-james.clark@arm.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf bpf: Fix build with libbpf 0.7.0 by checking if bpf_program__set_insns() is available</title>
<updated>2022-10-25T20:40:48+00:00</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2022-10-19T12:44:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f1bdebbb67bd21d7c5dfc42f313f2f54002440b8'/>
<id>urn:sha1:f1bdebbb67bd21d7c5dfc42f313f2f54002440b8</id>
<content type='text'>
During the transition to libbpf 1.0 some functions that perf used were
deprecated and finally removed from libbpf, so bpf_program__set_insns()
was introduced for perf to continue to use its bpf loader.

But when build with LIBBPF_DYNAMIC=1 we now need to check if that
function is available so that perf can build with older libbpf versions,
even if the end result is emitting a warning to the user that the use
of the perf BPF loader requires a newer libbpf, since bpf_program__set_insns()
touches libbpf objects internal state.

This affects only 'perf trace' when using bpf C code or pre-compiled
bytecode as an event.

Noticed on RHEL9, that has libbpf 0.7.0, where bpf_program__set_insns()
isn't available.

Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf test: Add build infra for perf test tools for ARM CoreSight tests</title>
<updated>2022-10-06T17:47:19+00:00</updated>
<author>
<name>Carsten Haitzler</name>
<email>carsten.haitzler@arm.com</email>
</author>
<published>2022-09-09T15:27:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=34bec35cbbb23e5fd18100f2a2b217ebb6cb129c'/>
<id>urn:sha1:34bec35cbbb23e5fd18100f2a2b217ebb6cb129c</id>
<content type='text'>
This adds the initial build infrastructure (makefiles maintainers
information) for adding follow-on tests for CoreSight.

Committer notes:

Remove the installation of tests/shell/coresight/*.sh, as there are no
files there yet and thus, at this point, make install fails.

Use $(QUIET_CLEAN) to avoid having extraneous output in the 'make clean'
output.

Also use @$(MAKE) in tools/perf/tests/shell/coresight/Makefile as $(Q)
is not turning into @ when V=1 isn't used, i.e. in the default case it
is not being quiet.

The &gt;/dev/null in the all for tools/perf/tests/shell/coresight/Makefile
is to avoid this:

  make[4]: Nothing to be done for 'all'.
  make[4]: Nothing to be done for 'all'.
  make[4]: Nothing to be done for 'all'.
    DESCEND plugins
    GEN     /tmp/build/perf/python/perf.so
  make[4]: Nothing to be done for 'all'.
    INSTALL trace_plugins

On !arm64 where nothing is done on the main target for
tools/perf/tests/shell/coresight/*/Makefile.

Signed-off-by: Carsten Haitzler &lt;carsten.haitzler@arm.com&gt;
Cc: Leo Yan &lt;leo.yan@linaro.org&gt;
Cc: Mathieu Poirier &lt;mathieu.poirier@linaro.org&gt;
Cc: Mike Leach &lt;mike.leach@linaro.org&gt;
Cc: Suzuki Poulouse &lt;suzuki.poulose@arm.com&gt;
Cc: coresight@lists.linaro.org
Link: http://lore.kernel.org/lkml/20220909152803.2317006-3-carsten.haitzler@foss.arm.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf build: Enable -Wthread-safety with clang</title>
<updated>2022-10-04T11:55:20+00:00</updated>
<author>
<name>Ian Rogers</name>
<email>irogers@google.com</email>
</author>
<published>2022-08-26T16:42:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dca571ed9753b4cd8d19d8b5a896351a78e3c5eb'/>
<id>urn:sha1:dca571ed9753b4cd8d19d8b5a896351a78e3c5eb</id>
<content type='text'>
If building with clang then enable -Wthread-safety warnings.

Signed-off-by: Ian Rogers &lt;irogers@google.com&gt;
Reviewed-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Alexandre Truong &lt;alexandre.truong@arm.com&gt;
Cc: Alexey Bayduraev &lt;alexey.v.bayduraev@linux.intel.com&gt;
Cc: Andi Kleen &lt;ak@linux.intel.com&gt;
Cc: Andres Freund &lt;andres@anarazel.de&gt;
Cc: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Cc: André Almeida &lt;andrealmeid@igalia.com&gt;
Cc: Athira Jajeev &lt;atrajeev@linux.vnet.ibm.com&gt;
Cc: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Cc: Colin Ian King &lt;colin.king@intel.com&gt;
Cc: Dario Petrillo &lt;dario.pk1@gmail.com&gt;
Cc: Darren Hart &lt;dvhart@infradead.org&gt;
Cc: Dave Marchevsky &lt;davemarchevsky@fb.com&gt;
Cc: Davidlohr Bueso &lt;dave@stgolabs.net&gt;
Cc: Fangrui Song &lt;maskray@google.com&gt;
Cc: Hewenliang &lt;hewenliang4@huawei.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: James Clark &lt;james.clark@arm.com&gt;
Cc: Jason Wang &lt;wangborong@cdjrlc.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Kajol Jain &lt;kjain@linux.ibm.com&gt;
Cc: Kim Phillips &lt;kim.phillips@amd.com&gt;
Cc: Leo Yan &lt;leo.yan@linaro.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Martin Liška &lt;mliska@suse.cz&gt;
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Nathan Chancellor &lt;nathan@kernel.org&gt;
Cc: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Cc: Pavithra Gurushankar &lt;gpavithrasha@gmail.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: Ravi Bangoria &lt;ravi.bangoria@amd.com&gt;
Cc: Remi Bernon &lt;rbernon@codeweavers.com&gt;
Cc: Riccardo Mancini &lt;rickyman7@gmail.com&gt;
Cc: Song Liu &lt;songliubraving@fb.com&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Thomas Richter &lt;tmricht@linux.ibm.com&gt;
Cc: Tom Rix &lt;trix@redhat.com&gt;
Cc: Weiguo Li &lt;liwg06@foxmail.com&gt;
Cc: Wenyu Liu &lt;liuwenyu7@huawei.com&gt;
Cc: William Cohen &lt;wcohen@redhat.com&gt;
Cc: Zechuan Chen &lt;chenzechuan1@huawei.com&gt;
Cc: bpf@vger.kernel.org
Cc: llvm@lists.linux.dev
Cc: yaowenbin &lt;yaowenbin1@huawei.com&gt;
Link: https://lore.kernel.org/r/20220826164242.43412-19-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>tools build: Increment room for feature name in feature detection output</title>
<updated>2022-10-04T11:55:19+00:00</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2022-08-18T12:09:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=74da7697a2ab988e3889ba4db78992a0944ea83d'/>
<id>urn:sha1:74da7697a2ab988e3889ba4db78992a0944ea83d</id>
<content type='text'>
Since now there are features with a long name, increase the room for them,
so that fields are correctly aligned.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: bpf@vger.kernel.org
Link: https://lore.kernel.org/r/20220818120957.319995-2-roberto.sassu@huaweicloud.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>tools build: Fix feature detection output due to eval expansion</title>
<updated>2022-10-04T11:55:19+00:00</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2022-08-18T12:09:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=709533e51b166d5a520589a03f0044ed304b33bd'/>
<id>urn:sha1:709533e51b166d5a520589a03f0044ed304b33bd</id>
<content type='text'>
As the first eval expansion is used only to generate Makefile statements,
messages should not be displayed at this stage, as for example conditional
expressions are not evaluated.

It can be seen for example in the output of feature detection for bpftool,
where the number of detected features does not change, despite turning on
the verbose mode (VF = 1) and there are additional features to display.

Fix this issue by escaping the $ before $(info) statements, to ensure that
messages are printed only when the function containing them is actually
executed, and not when it is expanded.

In addition, move the $(info) statement out of feature_print_status, due to
the fact that is called both inside and outside an eval context, and place
it to the caller so that the $ can be escaped when necessary. For symmetry,
move the $(info) statement also out of feature_print_text, and place it to
the caller.

Force the TMP variable evaluation in verbose mode, to display the features
in FEATURE_TESTS that are not in FEATURE_DISPLAY.

Reorder perf feature detection messages (first non-verbose, then verbose
ones) by moving the call to feature_display_entries earlier, before the VF
environment variable check.

Also, remove the newline from that function, as perf might display
additional messages. Move the newline to perf Makefile, and display another
one if displaying the detection result is not deferred as in the case of
bpftool.

Committer testing:

  Collecting the output from:

  $ make VF=1 -C tools/bpf/bpftool/ |&amp; grep "Auto-detecting system features" -A20

  $ diff -u before after
  --- before	2022-08-18 09:59:55.460529231 -0300
  +++ after	2022-08-18 10:01:11.182517282 -0300
  @@ -4,3 +4,5 @@
   ...              libbfd-liberty-z: [ on  ]
   ...                        libcap: [ on  ]
   ...               clang-bpf-co-re: [ on  ]
  +...        disassembler-four-args: [ on  ]
  +...      disassembler-init-styled: [ OFF ]
  $

Fixes: 0afc5cad387db560 ("perf build: Separate feature make support into config/Makefile.feature")
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: bpf@vger.kernel.org
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Quentin Monnet &lt;quentin@isovalent.com&gt;
Link: https://lore.kernel.org/r/20220818120957.319995-1-roberto.sassu@huaweicloud.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf python: Fix build when PYTHON_CONFIG is user supplied</title>
<updated>2022-08-27T14:55:16+00:00</updated>
<author>
<name>James Clark</name>
<email>james.clark@arm.com</email>
</author>
<published>2022-07-28T09:39:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bc9e7fe313d5e56d4d5f34bcc04d1165f94f86fb'/>
<id>urn:sha1:bc9e7fe313d5e56d4d5f34bcc04d1165f94f86fb</id>
<content type='text'>
The previous change to Python autodetection had a small mistake where
the auto value was used to determine the Python binary, rather than the
user supplied value. The Python binary is only used for one part of the
build process, rather than the final linking, so it was producing
correct builds in most scenarios, especially when the auto detected
value matched what the user wanted, or the system only had a valid set
of Pythons.

Change it so that the Python binary path is derived from either the
PYTHON_CONFIG value or PYTHON value, depending on what is specified by
the user. This was the original intention.

This error was spotted in a build failure an odd cross compilation
environment after commit 4c41cb46a732fe82 ("perf python: Prefer
python3") was merged.

Fixes: 630af16eee495f58 ("perf tools: Use Python devtools for version autodetection rather than runtime")
Signed-off-by: James Clark &lt;james.clark@arm.com&gt;
Acked-by: Ian Rogers &lt;irogers@google.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: James Clark &lt;james.clark@arm.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: https://lore.kernel.org/r/20220728093946.1337642-1-james.clark@arm.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>perf build: Remove FEATURE_CHECK_LDFLAGS-disassembler-{four-args,init-styled} setting</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:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dd6775f986144a9e0563dab70ef0398768227113'/>
<id>urn:sha1:dd6775f986144a9e0563dab70ef0398768227113</id>
<content type='text'>
As the building mechanism is now able to retry detection with different
combinations of linking flags, setting
FEATURE_CHECK_LDFLAGS-disassembler-four-args and
FEATURE_CHECK_LDFLAGS-disassembler-init-styled is not necessary anymore,
so remove it.

Committer notes:

Use the same technique to find the set of bfd-related libraries to link as in:

  3308ffc5016e6136 ("tools, build: Retry detection of bfd-related features")

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: 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: 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;
Cc: bpf@vger.kernel.org
Cc: llvm@lists.linux.dev
Link: https://lore.kernel.org/r/20220719170555.2576993-3-roberto.sassu@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>tools perf: Fix compilation error with new binutils</title>
<updated>2022-08-01T18:30:22+00:00</updated>
<author>
<name>Andres Freund</name>
<email>andres@anarazel.de</email>
</author>
<published>2022-08-01T01:38:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=83aa0120487e8bc3f231e72c460add783f71f17c'/>
<id>urn:sha1:83aa0120487e8bc3f231e72c460add783f71f17c</id>
<content type='text'>
binutils changed the signature of init_disassemble_info(), which now causes
compilation failures for tools/perf/util/annotate.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 perf can still disassemble bpf programs by using bpftrace
under load, recording a perf trace, and then annotating the bpf "function"
with and without the changes. With old binutils there's no change in output
before/after this patch. 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:

       1.15 :   55:mov    %rbp,%rdx
       0.00 :   58:add    $0xfffffffffffffff8,%rdx
       0.00 :   5c:xor    %ecx,%ecx
  -    1.03 :   5e:callq  0xffffffffe12aca3c
  +    1.03 :   5e:call   0xffffffffe12aca3c
       0.00 :   63:xor    %eax,%eax
  -    2.18 :   65:leaveq
  -    2.82 :   66:retq
  +    2.18 :   65:leave
  +    2.82 :   66: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: 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-5-andres@anarazel.de
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
</feed>
