Re: [PATCH v2 5/6] tools/build: selftests: Allow versioning LLVM lld

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Empty USE_LD variable causes clang build failure in selftests when ld.lld is not in PATH.
--

commit 371ca22c55bb0fa6502ac06f7b33d63418ad16ff
Author: James Clark <james.clark@linaro.org>

tools/build: selftests: Allow versioning LLVM lld

This commit adds an LLD variable to Makefile.include to allow versioning of
LLVM's linker, keeping it consistent with the rest of the LLVM toolchain. It
modifies the BPF selftests Makefile to resolve the full path of the linker
using the command -v shell utility.

> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 6ef6872adbc3e..836e783f0170e 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile

[ ... ]

> @@ -245,9 +245,9 @@ $(OUTPUT)/%:%.c
>  
>  # LLVM's ld.lld doesn't support all the architectures, so use it only on x86
>  ifeq ($(SRCARCH),$(filter $(SRCARCH),x86 riscv))
> -LLD := lld
> +USE_LD := $(shell command -v $(LLD))

Does this cause the build to fail if the toolchain directory is not in the
system PATH?

If a user explicitly specifies the compiler using an absolute path like
CLANG=/path/to/clang, but does not add the toolchain directory to their PATH,
the command -v utility will return an empty string.

This would cause USE_LD to be empty, leading to a malformed argument like
-fuse-ld= being passed to clang later in the Makefile, which then fails with
an invalid linker name error.

Previously, passing the hardcoded lld allowed clang to natively resolve the
linker relative to its own binary location. Is there a way to support both
versioned linker names and absolute compiler paths without relying entirely
on the system PATH?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518-james-perf-llvm-version-v2-0-f12cc4f031d8@linaro.org?part=5