Linux Perf Users
 help / color / mirror / Atom feed
From: James Clark <james.clark@linaro.org>
To: sashiko-reviews@lists.linux.dev, Ihor Solodrai <ihor.solodrai@linux.dev>
Cc: linux-perf-users@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH v3 4/5] tools/build: selftests: Allow versioning LLVM lld
Date: Wed, 15 Jul 2026 15:46:44 +0100	[thread overview]
Message-ID: <617b1d89-35f5-4dee-9aeb-eac7a0d34d38@linaro.org> (raw)
In-Reply-To: <20260715124513.8DA9E1F000E9@smtp.kernel.org>



On 15/07/2026 13:45, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] Bypassing Clang's internal linker path resolution causes silent linker version mismatches for out-of-path toolchains.
> - [Low] Unbalanced parenthesis in the `USE_LD_ERR` error messages.
> --
> 
> --- Patch [4]: [PATCH v3 4/5] tools/build: selftests: Allow versioning LLVM lld ---
> commit cdccb2d14502b0641ebfd4e8ddb945bdb605ed46
> Author: James Clark <james.clark@linaro.org>
> 
> tools/build: selftests: Allow versioning LLVM lld
> 
> This commit updates the BPF selftests Makefile to use the LLD variable
> from Makefile.include to ensure consistency with the rest of the LLVM
> toolchain. It explicitly resolves paths to the linker via shell commands
> and passes the result to clang's -fuse-ld flag.
> 
>> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
>> --- a/tools/testing/selftests/bpf/Makefile
>> +++ b/tools/testing/selftests/bpf/Makefile
>> @@ -264,30 +264,34 @@ $(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))
> 
> [Severity: Medium]
> Will this shell resolution cause silent linker version mismatches if a user
> builds with an out-of-path compiler (e.g., CLANG=/path/to/clang) without
> setting LLVM= or modifying the system PATH?
> 
> Previously, passing -fuse-ld=lld allowed clang to natively resolve the ld.lld
> binary relative to its own executable path. Bypassing clang's internal linker
> path resolution with `shell command -v` might cause the build to pick up a
> system linker (like /usr/bin/ld.lld) instead of the bundled one.
> 

I can just drop this patch. I assumed $LLD should behave like the other 
tools, but it's only used here where the compiler already picks it's 
sibling linker with the correct version.

>> +USE_LD_ERR = linker '$(LLD)' not found - add it to PATH, or pass LLVM=/path/ or LLD=/abs/ld.lld)
> 
> [Severity: Low]
> Is there an extra closing parenthesis at the end of this error message string?
> 
>>   else
>> -LLD := $(shell command -v $(LD))
>> +USE_LD := $(shell command -v $(LD))
>> +USE_LD_ERR = linker '$(LD)' not found - add it to PATH, or pass LLVM=/path/ or LD=/abs/ld)
> 
> [Severity: Low]
> Is there also an unbalanced closing parenthesis here?
> 
>>   endif
> 


  reply	other threads:[~2026-07-15 14:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15 12:39 [PATCH v3 0/5] tools/build: Allow versioning of all LLVM tools James Clark
2026-07-15 12:39 ` [PATCH v3 1/5] tools/build: Allow versioning of all LLVM tools defined in Makefile.include James Clark
2026-07-15 12:39 ` [PATCH v3 2/5] tools/build: Indent if else blocks James Clark
2026-07-15 12:39 ` [PATCH v3 3/5] tools/build: Allow versioning LLVM readelf James Clark
2026-07-15 12:39 ` [PATCH v3 4/5] tools/build: selftests: Allow versioning LLVM lld James Clark
2026-07-15 12:45   ` sashiko-bot
2026-07-15 14:46     ` James Clark [this message]
2026-07-15 12:39 ` [PATCH v3 5/5] tools/build: selftests: Remove some duplicate toolchain definitions James Clark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=617b1d89-35f5-4dee-9aeb-eac7a0d34d38@linaro.org \
    --to=james.clark@linaro.org \
    --cc=bpf@vger.kernel.org \
    --cc=ihor.solodrai@linux.dev \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox