linux-next.git/tools/scripts/Makefile.include, branch master

tools build: Only probe the compiler at parse time when it is installed

2026-08-12T13:17:48+00:00

Two parse-time probes still invoke $(CC) unconditionally: - LP64 in tools/scripts/Makefile.arch, probing with $(CC) -E -x c, pulled in twice by tools/perf/Makefile.perf; - CC_NO_CLANG in tools/scripts/Makefile.include, probing with $(CC) -dM -E -x c /dev/null. In the corner case where gcc is not yet installed, the very setup the install-build-deps target, added in the next patch of this series, is meant for, these probes make even targets that never compile parse-time spew errors like: /bin/sh: 1: gcc: not found /bin/sh: 1: gcc: not found /bin/sh: 1: gcc: not found Guard both probes with 'command -v' using the first word of CC so a missing compiler is handled silently with the same result as a failing probe (CC_NO_CLANG and LP64 unset/0), and with no behavior change when the compiler is installed. Only the first word is consulted because CC may carry arguments such as 'ccache gcc', and shell implementations differ in how 'command -v' handles multiple words (dash only checks the first, bash any of them), so validating the whole CC value would silently disable both probes on some make SHELLs. Assisted-by: opencode:deepseek-v4-flash-free Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim

tools/build: Allow versioning LLVM readelf

2026-07-26T05:25:00+00:00

Documentation/kbuild/llvm.rst mentions that readelf is included in the LLVM toolchain, but it's not currently included in this block. Add it so that LLVM=... options also apply to readelf. Users in tools/ were Perf which was hardcoding it, and another was the BPF makefile. Both already include Makefile.include so convert them to use the new variables. Where readelf wasn't doing anything arch specific, use HOSTREADELF because it's more likely to be installed. Reviewed-by: Ian Rogers Signed-off-by: James Clark Acked-by: Ihor Solodrai Acked-by: Kumar Kartikeya Dwivedi Signed-off-by: Namhyung Kim

tools/build: Indent if else blocks

2026-07-26T05:24:59+00:00

These blocks are quite big and unreadable without indentation. Indent them. No functional changes intended. Signed-off-by: James Clark Reviewed-by: Ian Rogers Acked-by: Kumar Kartikeya Dwivedi Signed-off-by: Namhyung Kim

tools/build: Allow versioning of all LLVM tools defined in Makefile.include

2026-07-26T05:24:59+00:00

The version of LLVM tools can be given on the build command with LLVM=-15, but this isn't applied to all tools. For example $(CC) gets versioned, but $(CLANG) doesn't. This causes a Perf build with LTO=1 to fail with an error about mixed clang versions: ld.lld: error: libperf/core.o: Unknown attribute kind (86) (Producer: 'LLVM18.1.8' Reader: 'LLVM 15.0.7') This file has two "ifneq ($(LLVM),)" blocks adjacent to each other, so merge these blocks making it obvious that all tools should be versioned consistently and there is nothing special about each block. This also reveals that ?= and "allow-override" are used inconsistently between the blocks. "allow-override" is technically only required for builtin variables, but isn't only used on them, and doesn't do any harm if used on a non-builtin. Make them all "allow-override" for consistency. The only functional difference this will cause is if there is a file level definition of one of the variables followed by an "#include of Makefile.include" which will now overwrite. But this isn't done and in a later commit some of the duplicate definitions will be removed for good measure. There are also some other LLVM tools that are not defined here and will be moved in a later commit. Signed-off-by: James Clark Reviewed-by: Ian Rogers Acked-by: Kumar Kartikeya Dwivedi Fixes: e9c281928c24 ("kbuild: Make $(LLVM) more flexible") Signed-off-by: Namhyung Kim

tools/build: Reject unexpected values for LLVM=

2026-03-03T16:42:11+00:00

Since commit 502678b88cb3 ("kbuild: Reject unexpected values for LLVM=") the regular kbuild rejects unexpected values of LLVM=1 instead of silently treating them as LLVM=1. Align the tools build to kbuild. Signed-off-by: Thomas Weißschuh Reviewed-by: Nicolas Schier Reviewed-by: Nathan Chancellor Link: https://patch.msgid.link/20260226-kbuild-llvm-followup-v1-2-201cc2a492d9@weissschuh.net Signed-off-by: Nicolas Schier

perf test workload: Add code_with_type test workload

2026-02-08T22:16:24+00:00

The purpose of the workload is to gather samples of rust runtime. To achieve that it has a dummy rust library linked with it. Per recommendations for such scenarios [1], the rust library is statically linked. An example: $ perf record perf test -w code_with_type [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.160 MB perf.data (4074 samples) ] $ perf report --stdio --dso perf -s srcfile,srcline 45.16% ub_checks.rs ub_checks.rs:72 6.72% code_with_type.rs code_with_type.rs:15 6.64% range.rs range.rs:767 4.26% code_with_type.rs code_with_type.rs:21 4.23% range.rs range.rs:0 3.99% code_with_type.rs code_with_type.rs:16 [...] [1]: https://doc.rust-lang.org/reference/linkage.html#mixed-rust-and-foreign-codebases Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com> Tested-by: Arnaldo Carvalho de Melo Cc: Ian Rogers Cc: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo

tools/build: Fix s390(x) cross-compilation with clang

2025-07-08T07:19:23+00:00

The heuristic to derive a clang target triple from a GCC one does not work for s390. GCC uses "s390-linux" while clang expects "s390x-linux" or "powerz-linux". Add an explicit override. Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20250620-tools-cross-s390-v2-1-ecda886e00e5@linutronix.de Signed-off-by: Thomas Weißschuh

Merge tag 'trace-tools-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

2025-03-28T00:03:01+00:00

Pull tracing tooling updates from Steven Rostedt: - Allow RTLA to collect data via BPF The current implementation of rtla uses libtracefs and libtraceevent to pull sample events generated by the timerlat tracer from the trace buffer. rtla then processes the sample by updating the histogram and summary (current, maximum, minimum, and sum values) as well as checks if tracing has been stopped due to threshold overflow. In use cases where a large number of samples is being generated, that is, with measurements running on many CPUs and with a low interval, this sample processing design causes a significant CPU load on the rtla side. Furthermore, with >100 CPUs and 100us interval, rtla was reported as not being able to keep up with the samples and dropping most of them, leading to it being unusable. Change the way the timerlat trace processes samples by attaching a BPF program to the trace event using the BPF skeleton feature of bpftool. Unlike the current implementation, the BPF implementation does not check whether tracing is stopped (in BPF mode, tracing is always off to improve performance), but waits for a write to a BPF ringbuffer instead. This allows rtla to exit immediately when a threshold is violated, without waiting for the next iteration of the while loop. If the requirements for the BPF implementation are not met, either at build time or at run time, the current implementation is used as fallback. Which implementation is being used can be seen when running rtla timerlat with "-D" option. rtla can be forced to run in non-BPF mode by setting the RTLA_NO_BPF option to 1, for debugging purposes. - Fix LD_FLAGS from being dropped in build - Refactor code to remove duplication of save_trace_to_file - Always set options and do not rely on default settings Do not rely on the default kernel settings of the tracers when starting. They could have been changed by the user which gives inconsistent results. Always set the options that rtla expects. - Add creation of ctags and TAGS for traversing code * tag 'trace-tools-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: rtla: Add the ability to create ctags and etags rtla/tests: Test setting default options rtla/tests: Reset osnoise options before check rtla: Always set all tracer options rtla/osnoise: Set OSNOISE_WORKLOAD to true rtla: Unify apply_config between top and hist rtla/osnoise: Unify params struct rtla: Fix segfault in save_trace_to_file call tools/build: Use SYSTEM_BPFTOOL for system bpftool rtla: Refactor save_trace_to_file tools/rv: Keep user LDFLAGS in build rtla/timerlat: Test BPF mode rtla/timerlat_top: Use BPF to collect samples rtla/timerlat_top: Move divisor to update rtla/timerlat_hist: Use BPF to collect samples rtla/timerlat: Add BPF skeleton to collect samples rtla: Add optional dependency on BPF tooling tools/build: Add bpftool-skeletons feature test rtla/timerlat: Unify params struct

tools/build: Use SYSTEM_BPFTOOL for system bpftool

2025-03-26T14:31:31+00:00

The feature test for system bpftool uses BPFTOOL as the variable to set its path, defaulting to just "bpftool" if not set by the user. This conflicts with selftests and a few other utilities, which expect BPFTOOL to be set to the in-tree bpftool path by default. For example, bpftool selftests fail to build: $ make -C tools/testing/selftests/bpf/ make: Entering directory '/home/tglozar/dev/linux/tools/testing/selftests/bpf' make: *** No rule to make target 'bpftool', needed by '/home/tglozar/dev/linux/tools/testing/selftests/bpf/tools/include/vmlinux.h'. Stop. make: Leaving directory '/home/tglozar/dev/linux/tools/testing/selftests/bpf' Fix the problem by renaming the variable used for system bpftool from BPFTOOL to SYSTEM_BPFTOOL, so that the new usage does not conflict with the existing one of BPFTOOL. Cc: John Kacur Cc: Luis Goncalves Link: https://lore.kernel.org/20250326004018.248357-1-tglozar@redhat.com Fixes: 8a635c3856dd ("tools/build: Add bpftool-skeletons feature test") Closes: https://lore.kernel.org/linux-kernel/5df6968a-2e5f-468e-b457-fc201535dd4c@linux.ibm.com/ Reported-by: Venkat Rao Bagalkote Tested-by: Venkat Rao Bagalkote Suggested-by: Quentin Monnet Acked-by: Quentin Monnet Signed-off-by: Tomas Glozar Signed-off-by: Steven Rostedt (Google)

tools/build: Add bpftool-skeletons feature test

2025-03-04T17:35:17+00:00

Add bpftool-skeletons feature test, testing the presence of a bpftool capable of generating skeletons. This is to be used for tools that do not require building their own bootstrap bpftool from the kernel source tree. Cc: John Kacur Cc: Luis Goncalves Cc: Gabriele Monaco Cc: Clark Williams Link: https://lore.kernel.org/20250218145859.27762-3-tglozar@redhat.com Signed-off-by: Tomas Glozar Signed-off-by: Steven Rostedt (Google)