kernel/tools/perf/Makefile.config, branch linux-6.17.y

perf build: Don't fail fast path feature detection when binutils-devel is not available

2025-11-24T09:37:38Z

[ Upstream commit a09e5967ad6819379fd31894634d7aed29c18409 ] This is one more remnant of the BUILD_NONDISTRO series to make building with binutils-devel opt-in due to license incompatibility. In this case just the references at link time were still in place, which make building the test-all.bin file fail, which wasn't detected before probably because the last test was done with binutils-devel available, doh. Now: $ rpm -q binutils-devel package binutils-devel is not installed $ file /tmp/build/perf-tools/feature/test-all.bin /tmp/build/perf-tools/feature/test-all.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=4b5388a346b51f1b993f0b0dbd49f4570769b03c, for GNU/Linux 3.2.0, not stripped $ Fixes: 970ae86307718c34 ("perf build: The bfd features are opt-in, stop testing for them by default") Reviewed-by: Ian Rogers Cc: Adrian Hunter Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

tools: Remove libcrypto dependency

2025-06-26T17:51:41Z

Remove all occurrence of libcrypto in the build system. Signed-off-by: Yuzhuo Jing Signed-off-by: Eric Biggers Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250625202311.23244-5-ebiggers@kernel.org Signed-off-by: Namhyung Kim

perf build: enable -fno-strict-aliasing

2025-06-26T17:51:40Z

perf pulls in code from kernel headers that assumes it is being built with -fno-strict-aliasing, namely put_unaligned_*() from which write the data using packed structs that lack the may_alias attribute. Enable -fno-strict-aliasing to prevent miscompilations in sha1.c which would otherwise occur due to this issue. Signed-off-by: Eric Biggers Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250625202311.23244-2-ebiggers@kernel.org Signed-off-by: Namhyung Kim

perf build: The bfd features are opt-in, stop testing for them by default

2025-06-24T17:27:50Z

These are leftovers noticed while updating a build container. We don't need those so that test-all.c can build and thus speed up the feature detection. Test for those features only if the user asks for BUILD_NONDISTRO=1 to build with libbfd. Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: James Clark Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250620212435.93846-4-acme@kernel.org Signed-off-by: Namhyung Kim

perf build: Add the libpfm devel fedora package name to the hint

2025-06-24T17:27:50Z

Just to follow the pattern with other devel packages. Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: James Clark Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250620212435.93846-3-acme@kernel.org Signed-off-by: Namhyung Kim

perf build: Suggest java-latest-openjdk-devel instead of old 1.8.0 one

2025-06-24T17:27:49Z

Just tidying up the suggestion to pick the latest and not some specific version. Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: James Clark Reviewed-by: Ian Rogers Link: https://lore.kernel.org/r/20250620212435.93846-2-acme@kernel.org Signed-off-by: Namhyung Kim

perf build: detect support for libbpf's emit_strings option

2025-06-20T21:48:14Z

This creates a config option that detects libbpf's ability to display character arrays as strings, which was just added to the BPF tree (https://git.kernel.org/bpf/bpf-next/c/87c9c79a02b4). To test this change, I built perf (from later in this patch set) with: - static libbpf (default, using source from kernel tree) - dynamic libbpf (LIBBPF_DYNAMIC=1 LIBBPF_INCLUDE=/usr/local/include) For both the static and dynamic versions, I used headers with and without the ".emit_strings" option. I verified that of the four resulting binaries, the two with ".emit_strings" would successfully record BPF_METADATA events, and the two without wouldn't. All four binaries would successfully display BPF_METADATA events, because the relevant bit of libbpf code is only used during "perf record". Signed-off-by: Blake Jones Link: https://lore.kernel.org/r/20250612194939.162730-2-blakejones@google.com Signed-off-by: Namhyung Kim

Merge remote-tracking branch 'torvalds/master' into perf-tools-next

2025-05-07T15:51:38Z

To pick up fixes from the latest perf-tools pull request from Namhyung and get perf-tools-next in line with thinngs in other areas it uses, like tools/lib/bpf, etc. Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Fix in-source libperf build

2025-04-29T19:32:31Z

When libperf is built alone in-source, $(OUTPUT) isn't set. This causes the generated uapi path to resolve to '/../arch' which results in a permissions error: mkdir: cannot create directory '/../arch': Permission denied Fix it by removing the preceding '/..' which means that it gets generated either in the tools/lib/perf part of the tree or the OUTPUT folder. Some other rules that rely on OUTPUT further refine this conditionally depending on whether it's an in-source or out-of-source build, but I don't think we need the extra complexity here. And this rule is slightly different to others because the header is needed by both libperf and Perf. This is further complicated by the fact that Perf always passes O=... to libperf even for in source builds, meaning that OUTPUT isn't set consistently between projects. Because we're no longer going one level up to try to generate the file in the tools/ folder, Perf's include rule needs to descend into libperf. Also fix the clean rule while we're here. Reported-by: Thorsten Leemhuis Closes: https://lore.kernel.org/linux-perf-users/7703f88e-ccb7-4c98-9da4-8aad224e780f@leemhuis.info/ Fixes: bfb713ea53c7 ("perf tools: Fix arm64 build by generating unistd_64.h") Signed-off-by: James Clark Tested-by: Thorsten Leemhuis Link: https://lore.kernel.org/r/20250429-james-perf-fix-libperf-in-source-build-v1-1-a1a827ac15e5@linaro.org Signed-off-by: Namhyung Kim

perf tools: Fix arm64 build by generating unistd_64.h

2025-04-23T15:57:12Z

Since pulling in the kernel changes in commit 22f72088ffe6 ("tools headers: Update the syscall table with the kernel sources"), arm64 is no longer using a generic syscall header and generates one from the syscall table. Therefore we must also generate the syscall header for arm64 before building Perf. Add it as a dependency to libperf which uses one syscall number. Perf uses more, but as libperf is a dependency of Perf it will be generated for both. Future platforms that need this will have to add their own syscall-y targets in libperf manually. Unfortunately the arch specific files that do this (e.g. arch/arm64/include/asm/Kbuild) can't easily be imported into the Perf build. But Perf only needs a subset of the generated files anyway, so redefining them is probably the correct thing to do. Fixes: 22f72088ffe6 ("tools headers: Update the syscall table with the kernel sources") Signed-off-by: James Clark Tested-by: Harshit Mogalapalli Link: https://lore.kernel.org/r/20250417-james-perf-fix-gen-syscall-v1-1-1d268c923901@linaro.org Signed-off-by: Namhyung Kim