pm24.git/tools/build, branch rust-6.13

perf build: Remove unused feature test target

2024-09-10T20:32:47Z

llvm-version was removed in commit 56b11a2126bf ("perf bpf: Remove support for embedding clang for compiling BPF events (-e foo.c)") but some parts were left in the Makefile so finish removing them. Signed-off-by: James Clark Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Bill Wendling Cc: Changbin Du Cc: Daniel Wagner Cc: Guilherme Amadio Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Justin Stitt Cc: Kan Liang Cc: Leo Yan Cc: Manu Bretelle Cc: Mark Rutland Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Peter Zijlstra Cc: Quentin Monnet Cc: Steinar H. Gunderson Link: https://lore.kernel.org/r/20240910140405.568791-2-james.clark@linaro.org [ Removed one leftover, 'llvm-version' from FEATURE_TESTS_EXTRA ] Signed-off-by: Arnaldo Carvalho de Melo

perf build: Autodetect minimum required llvm-dev version

2024-09-10T20:32:46Z

The new LLVM addr2line feature requires a minimum version of 13 to compile. Add a feature check for the version so that NO_LLVM=1 doesn't need to be explicitly added. Leave the existing llvm feature check intact because it's used by tools other than Perf. This fixes the following compilation error when the llvm-dev version doesn't match: util/llvm-c-helpers.cpp: In function 'char* llvm_name_for_code(dso*, const char*, u64)': util/llvm-c-helpers.cpp:178:21: error: 'std::remove_reference_t' {aka 'struct llvm::DILineInfo'} has no member named 'StartAddress' 178 | addr, res_or_err->StartAddress ? *res_or_err->StartAddress : 0); Fixes: c3f8644c21df9b7d ("perf report: Support LLVM for addr2line()") Signed-off-by: James Clark Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Bill Wendling Cc: Changbin Du Cc: Guilherme Amadio Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Justin Stitt Cc: Kan Liang Cc: Leo Yan Cc: Manu Bretelle Cc: Mark Rutland Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Peter Zijlstra Cc: Quentin Monnet Cc: Steinar H. Gunderson Link: https://lore.kernel.org/r/20240910140405.568791-1-james.clark@linaro.org Signed-off-by: Arnaldo Carvalho de Melo

perf report: Support LLVM for addr2line()

2024-09-03T13:15:16Z

In addition to the existing support for libbfd and calling out to an external addr2line command, add support for using libllvm directly. This is both faster than libbfd, and can be enabled in distro builds (the LLVM license has an explicit provision for GPLv2 compatibility). Thus, it is set as the primary choice if available. As an example, running 'perf report' on a medium-size profile with DWARF-based backtraces took 58 seconds with LLVM, 78 seconds with libbfd, 153 seconds with external llvm-addr2line, and I got tired and aborted the test after waiting for 55 minutes with external bfd addr2line (which is the default for perf as compiled by distributions today). Evidently, for this case, the bfd addr2line process needs 18 seconds (on a 5.2 GHz Zen 3) to load the .debug ELF in question, hits the 1-second timeout and gets killed during initialization, getting restarted anew every time. Having an in-process addr2line makes this much more robust. As future extensions, libllvm can be used in many other places where we currently use libbfd or other libraries: - Symbol enumeration (in particular, for PE binaries). - Demangling (including non-Itanium demangling, e.g. Microsoft or Rust). - Disassembling (perf annotate). However, these are much less pressing; most people don't profile PE binaries, and perf has non-bfd paths for ELF. The same with demangling; the default _cxa_demangle path works fine for most users, and while bfd objdump can be slow on large binaries, it is possible to use --objdump=llvm-objdump to get the speed benefits. (It appears LLVM-based demangling is very simple, should we want that.) Tested with LLVM 14, 15, 16, 18 and 19. For some reason, LLVM 12 was not correctly detected using feature_check, and thus was not tested. Committer notes: Added the name and a __maybe_unused to address: 1 13.50 almalinux:8 : FAIL gcc version 8.5.0 20210514 (Red Hat 8.5.0-22) (GCC) util/srcline.c: In function 'dso__free_a2l': util/srcline.c:184:20: error: parameter name omitted void dso__free_a2l(struct dso *) ^~~~~~~~~~~~ make[3]: *** [/git/perf-6.11.0-rc3/tools/build/Makefile.build:158: util] Error 2 Signed-off-by: Steinar H. Gunderson Tested-by: Arnaldo Carvalho de Melo Cc: Ian Rogers Link: https://lore.kernel.org/r/20240803152008.2818485-1-sesse@google.com Signed-off-by: Arnaldo Carvalho de Melo

Revert "tools build: Remove leftover libcap tests that prevents fast path feature detection from working"

2024-08-29T14:51:43Z

Ian pointed out that the libcap feature test is also used by bpftool, so we can't remove it just because perf stopped using it, revert the removal of the feature test. Since both perf and libcap uses the fast path feature detection (tools/build/feature/test-all.c), probably the best thing is to keep libcap-devel when building perf even it not being used there. This reverts commit 47b3b6435e4bfb61ae8ffc63a11bd3c310f69acf. Cc: Adrian Hunter Cc: Ian Rogers Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo

tools build: Remove leftover libcap tests that prevents fast path feature detection from working

2024-08-28T22:11:36Z

I noticed that the fast path feature detection was failing: $ cat /tmp/build/perf-tools-next/feature/test-all.make.output /usr/bin/ld: cannot find -lcap: No such file or directory collect2: error: ld returned 1 exit status $ The patch removing the dependency (Fixes tag below) didn't remove the detection of libcap, and as the fast path feature detection (test-all.c) had -lcap in its Makefile link list of libraries to link, it was failing when libcap-devel is not available, fix it by removing those leftover files. Fixes: e25ebda78e230283 ("perf cap: Tidy up and improve capability testing") Cc: Adrian Hunter Cc: Ian Rogers Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Link: https://lore.kernel.org/lkml/Zs-gjOGFWtAvIZit@x1 Signed-off-by: Arnaldo Carvalho de Melo

tools build: Provide consistent build options for fixdep

2024-08-15T21:08:17Z

The fixdep binary is being compiled and linked in one step. While the host linker flags are passed to the compiler the host compiler flags are missed. That leads to build errors at least on x86_64, arm64 and s390 as result of the compiler vs linker flags inconsistency. For example, during RPM package build redhat-hardened-ld script is provided to gcc, while redhat-hardened-cc1 script is missed. Provide both KBUILD_HOSTCFLAGS and KBUILD_HOSTLDFLAGS to avoid that. Fixes: ea974028a049f2ce ("tools build: Avoid circular .fixdep-in.o.cmd issues") Closes: https://lore.kernel.org/lkml/99ae0d34-ed76-4ca0-a9fd-c337da33c9f9@leemhuis.info/ Reported-by: Thorsten Leemhuis Reviewed-by: Brian Norris Signed-off-by: Alexander Gordeev Tested-by: Thorsten Leemhuis Acked-by: Jiri Olsa Link: https://lore.kernel.org/r/20240815072046.1002837-1-agordeev@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo

perf build: Fix up broken capstone feature detection fast path

2024-08-14T13:44:26Z

The capstone devel headers define 'struct bpf_insn' in a way that clashes with what is in the libbpf devel headers, so we so far need to avoid including both. This is happening on the tools/build/feature/test-all.c file, where we try building all the expected set of libraries to be normally available on a system: ⬢[acme@toolbox perf-tools-next]$ cat /tmp/build/perf-tools-next/feature/test-all.make.output In file included from test-bpf.c:3, from test-all.c:150: /home/acme/git/perf-tools-next/tools/include/uapi/linux/bpf.h:77:8: error: ‘bpf_insn’ defined as wrong kind of tag 77 | struct bpf_insn { | ^~~~~~~~ ⬢[acme@toolbox perf-tools-next]$ cat /tmp/build/perf-tools-next/feature/test-all.make.output When doing so there is a trick where we define main to be main_test_libcapstone, then include the individual tools/build/feture/test-libcapstone.c capability query test, and then we undef 'main' because we'll do it all over again with the next expected library to be tested (at this time 'lzma'). To complete this mechanism we need to, in test-all.c 'main' routine, to call main_test_libcapstone(), which isn't being done, so the effect of adding references to capstone in test-all.c are not achieved. The only thing that is happening is that test-all.c is failing to build and thus all the tests will have to be done individually, which nullifies the test-all.c single build speedup. So lets remove references to capstone from test-all.c to see if this makes it build again so that we get faster builds or go on fixing up whatever is preventing us to get that benefit. Nothing: after this fix we get a clean test-all.c build and get the build speedup back: ⬢[acme@toolbox perf-tools-next]$ cat /tmp/build/perf-tools-next/feature/test-all.make.output ⬢[acme@toolbox perf-tools-next]$ cat /tmp/build/perf-tools-next/feature/test-all. test-all.bin test-all.d test-all.make.output ⬢[acme@toolbox perf-tools-next]$ cat /tmp/build/perf-tools-next/feature/test-all.make.output ⬢[acme@toolbox perf-tools-next]$ ldd /tmp/build/perf-tools-next/feature/test-all.bin linux-vdso.so.1 (0x00007f13277a1000) libpython3.12.so.1.0 => /lib64/libpython3.12.so.1.0 (0x00007f1326e00000) libm.so.6 => /lib64/libm.so.6 (0x00007f13274be000) libtraceevent.so.1 => /lib64/libtraceevent.so.1 (0x00007f1327496000) libtracefs.so.1 => /lib64/libtracefs.so.1 (0x00007f132746f000) libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f1326800000) libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8 (0x00007f1327452000) libunwind.so.8 => /lib64/libunwind.so.8 (0x00007f1327436000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f1327403000) libdw.so.1 => /lib64/libdw.so.1 (0x00007f1326d6f000) libz.so.1 => /lib64/libz.so.1 (0x00007f13273e2000) libelf.so.1 => /lib64/libelf.so.1 (0x00007f1326d53000) libnuma.so.1 => /lib64/libnuma.so.1 (0x00007f13273d4000) libslang.so.2 => /lib64/libslang.so.2 (0x00007f1326400000) libperl.so.5.38 => /lib64/libperl.so.5.38 (0x00007f1326000000) libc.so.6 => /lib64/libc.so.6 (0x00007f1325e0f000) libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f1326741000) /lib64/ld-linux-x86-64.so.2 (0x00007f13277a3000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f1326d3f000) libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f1326d07000) ⬢[acme@toolbox perf-tools-next]$ And when having capstone-devel installed we get it detected and linked with perf, allowing us to benefit from the features that it enables: ⬢[acme@toolbox perf-tools-next]$ rpm -q capstone-devel capstone-devel-5.0.1-3.fc40.x86_64 ⬢[acme@toolbox perf-tools-next]$ ldd /tmp/build/perf-tools-next/perf | grep capstone libcapstone.so.5 => /lib64/libcapstone.so.5 (0x00007fe6a5c00000) ⬢[acme@toolbox perf-tools-next]$ /tmp/build/perf-tools-next/perf -vv | grep cap libcapstone: [ on ] # HAVE_LIBCAPSTONE_SUPPORT ⬢[acme@toolbox perf-tools-next]$ Fixes: 8b767db3309595a2 ("perf: build: introduce the libcapstone") Cc: Adrian Hunter Cc: Andi Kleen Cc: Changbin Du Cc: Ian Rogers Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Link: https://lore.kernel.org/lkml/Zry0sepD5Ppa5YKP@x1 Signed-off-by: Arnaldo Carvalho de Melo

tools build: Correct bpf fixdep dependencies

2024-08-05T15:19:48Z

The dependencies in tools/lib/bpf/Makefile are incorrect. Before we recurse to build $(BPF_IN_STATIC), we need to build its 'fixdep' executable. I can't use the usual shortcut from Makefile.include: : fixdep because its 'fixdep' target relies on $(OUTPUT), and $(OUTPUT) differs in the parent 'make' versus the child 'make' -- so I imitate it via open-coding. I tweak a few $(MAKE) invocations while I'm at it, because 1. I'm adding a new recursive make; and 2. these recursive 'make's print spurious lines about files that are "up to date" (which isn't normally a feature in Kbuild subtargets) or "jobserver not available" (see [1]) I also need to tweak the assignment of the OUTPUT variable, so that relative path builds work. For example, for 'make tools/lib/bpf', OUTPUT is unset, and is usually treated as "cwd" -- but recursive make will change cwd and so OUTPUT has a new meaning. For consistency, I ensure OUTPUT is always an absolute path. And $(Q) gets a backup definition in tools/build/Makefile.include, because Makefile.include is sometimes included without tools/build/Makefile, so the "quiet command" stuff doesn't actually work consistently without it. After this change, top-level builds result in an empty grep result from: $ grep 'cannot find fixdep' $(find tools/ -name '*.cmd') [1] https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html If we're not using $(MAKE) directly, then we need to use more '+'. Signed-off-by: Brian Norris Acked-by: Andrii Nakryiko Acked-by: Jiri Olsa Cc: Ian Rogers Cc: Josh Poimboeuf Cc: Masahiro Yamada Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Richter Link: https://lore.kernel.org/r/20240715203325.3832977-4-briannorris@chromium.org Signed-off-by: Arnaldo Carvalho de Melo

tools build: Avoid circular .fixdep-in.o.cmd issues

2024-08-05T15:09:14Z

The 'fixdep' tool is used to post-process dependency files for various reasons, and it runs after every object file generation command. This even includes 'fixdep' itself. In Kbuild, this isn't actually a problem, because it uses a single command to generate fixdep (a compile-and-link command on fixdep.c), and afterward runs the fixdep command on the accompanying .fixdep.cmd file. In tools/ builds (which notably is maintained separately from Kbuild), fixdep is generated in several phases: 1. fixdep.c -> fixdep-in.o 2. fixdep-in.o -> fixdep Thus, fixdep is not available in the post-processing for step 1, and instead, we generate .cmd files that look like: ## from tools/objtool/libsubcmd/.fixdep.o.cmd # cannot find fixdep (/path/to/linux/tools/objtool/libsubcmd//fixdep) [...] These invalid .cmd files are benign in some respects, but cause problems in others (such as the linked reports). Because the tools/ build system is rather complicated in its own right (and pointedly different than Kbuild), I choose to simply open-code the rule for building fixdep, and avoid the recursive-make indirection that produces the problem in the first place. Signed-off-by: Brian Norris Acked-by: Jiri Olsa Cc: Ian Rogers Cc: Josh Poimboeuf Cc: Masahiro Yamada Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Richter Link: https://lore.kernel.org/all/Zk-C5Eg84yt6_nml@google.com/ Link: https://lore.kernel.org/r/20240715203325.3832977-3-briannorris@chromium.org Signed-off-by: Arnaldo Carvalho de Melo

Merge tag 'perf-tools-fixes-for-v6.11-2024-07-30' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools

2024-07-31T02:22:41Z

Pull perf tools fixes from Namhyung Kim: "Some more build fixes and a random crash fix: - Fix cross-build by setting pkg-config env according to the arch - Fix static build for missing library dependencies - Fix Segfault when callchain has no symbols" * tag 'perf-tools-fixes-for-v6.11-2024-07-30' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: perf docs: Document cross compilation perf: build: Link lib 'zstd' for static build perf: build: Link lib 'lzma' for static build perf: build: Only link libebl.a for old libdw perf: build: Set Python configuration for cross compilation perf: build: Setup PKG_CONFIG_LIBDIR for cross compilation perf tool: fix dereferencing NULL al->maps