[PATCH 0/2] Link the PowerPC vDSO with ld.lld

[PATCH 0/2] Link the PowerPC vDSO with ld.lld

[Nathan Chancellor]

Hi all,

This series is an alternative to the one proposed by Nick before the
PowerPC vDSO unification in commit fd1feade75fb ("powerpc/vdso: Merge
vdso64 and vdso32 into a single directory"):

https://lore.kernel.org/20200901222523.1941988-1-ndesaulniers@google.com/

Normally, we try to make compiling and linking two separate stages so
that they can be done by $(CC) and $(LD) respectively, which is more in
line with what the user expects, versus using the compiler as a linker
driver and relying on the implicit default linker value. However, as
shown in the above thread, getting this right for the PowerPC vDSO is a
little tricky due to the linker emulation values.

The unification might make this easier but that needs further
investigation. To avoid regressing ld.bfd while enabling support for
linking the vDSO with ld.lld, we can tell the compiler to use ld.lld via
either '--ld-path=' (clang 12.0.0) or '-fuse-ld=lld'.

The first patch avoids a warning from ld.lld when linking both vDSO
objects and the second patch adds the flags.

This should help avoid the issue noticed during Alexey's LTO bring up:

https://lore.kernel.org/CAKwvOdmUMhqhQhDCpWjMNiQQPvwOJB9MbUkF3RR0BL+H+DagmA@mail.gmail.com/

Nathan Chancellor (2):
  powerpc/vdso: Remove unused ENTRY in linker scripts
  powerpc/vdso: Link with ld.lld when requested

 arch/powerpc/kernel/vdso/Makefile     | 1 +
 arch/powerpc/kernel/vdso/vdso32.lds.S | 1 -
 arch/powerpc/kernel/vdso/vdso64.lds.S | 1 -
 3 files changed, 1 insertion(+), 2 deletions(-)


base-commit: f06351f8c0c85e2d53e73c53a33b4ef55b4ad6de
-- 
2.36.1

[PATCH 1/2] powerpc/vdso: Remove unused ENTRY in linker scripts

[Nathan Chancellor]

When linking vdso{32,64}.so.dbg with ld.lld, there is a warning about
not finding _start for the starting address:

  ld.lld: warning: cannot find entry symbol _start; not setting start address
  ld.lld: warning: cannot find entry symbol _start; not setting start address

Looking at GCC + GNU ld, the entry point address is 0x0:

  $ llvm-readelf -h vdso{32,64}.so.dbg &| rg "(File|Entry point address):"
  File: vdso32.so.dbg
    Entry point address:               0x0
  File: vdso64.so.dbg
    Entry point address:               0x0

This matches what ld.lld emits:

  $ powerpc64le-linux-gnu-readelf -p .comment vdso{32,64}.so.dbg

  File: vdso32.so.dbg

  String dump of section '.comment':
    [     0]  Linker: LLD 14.0.0
    [    14]  clang version 14.0.0 (Fedora 14.0.0-1.fc37)

  File: vdso64.so.dbg

  String dump of section '.comment':
    [     0]  Linker: LLD 14.0.0
    [    14]  clang version 14.0.0 (Fedora 14.0.0-1.fc37)

  $ llvm-readelf -h vdso{32,64}.so.dbg &| rg "(File|Entry point address):"
  File: vdso32.so.dbg
    Entry point address:               0x0
  File: vdso64.so.dbg
    Entry point address:               0x0

Remove ENTRY to remove the warning, as it is unnecessary for the vDSO to
function correctly.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/powerpc/kernel/vdso/vdso32.lds.S | 1 -
 arch/powerpc/kernel/vdso/vdso64.lds.S | 1 -
 2 files changed, 2 deletions(-)

diff --git a/arch/powerpc/kernel/vdso/vdso32.lds.S b/arch/powerpc/kernel/vdso/vdso32.lds.S
index 58e0099f70f4..e0d19d74455f 100644
--- a/arch/powerpc/kernel/vdso/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso/vdso32.lds.S
@@ -13,7 +13,6 @@ OUTPUT_FORMAT("elf32-powerpcle", "elf32-powerpcle", "elf32-powerpcle")
 OUTPUT_FORMAT("elf32-powerpc", "elf32-powerpc", "elf32-powerpc")
 #endif
 OUTPUT_ARCH(powerpc:common)
-ENTRY(_start)
 
 SECTIONS
 {
diff --git a/arch/powerpc/kernel/vdso/vdso64.lds.S b/arch/powerpc/kernel/vdso/vdso64.lds.S
index 0288cad428b0..1a4a7bc4c815 100644
--- a/arch/powerpc/kernel/vdso/vdso64.lds.S
+++ b/arch/powerpc/kernel/vdso/vdso64.lds.S
@@ -13,7 +13,6 @@ OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle")
 OUTPUT_FORMAT("elf64-powerpc", "elf64-powerpc", "elf64-powerpc")
 #endif
 OUTPUT_ARCH(powerpc:common64)
-ENTRY(_start)
 
 SECTIONS
 {
-- 
2.36.1

Re: [PATCH 1/2] powerpc/vdso: Remove unused ENTRY in linker scripts

[Nick Desaulniers]

On Mon, May 9, 2022 at 1:46 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> When linking vdso{32,64}.so.dbg with ld.lld, there is a warning about
> not finding _start for the starting address:
>
>   ld.lld: warning: cannot find entry symbol _start; not setting start address
>   ld.lld: warning: cannot find entry symbol _start; not setting start address
>
> Looking at GCC + GNU ld, the entry point address is 0x0:
>
>   $ llvm-readelf -h vdso{32,64}.so.dbg &| rg "(File|Entry point address):"
>   File: vdso32.so.dbg
>     Entry point address:               0x0
>   File: vdso64.so.dbg
>     Entry point address:               0x0
>
> This matches what ld.lld emits:
>
>   $ powerpc64le-linux-gnu-readelf -p .comment vdso{32,64}.so.dbg
>
>   File: vdso32.so.dbg
>
>   String dump of section '.comment':
>     [     0]  Linker: LLD 14.0.0
>     [    14]  clang version 14.0.0 (Fedora 14.0.0-1.fc37)
>
>   File: vdso64.so.dbg
>
>   String dump of section '.comment':
>     [     0]  Linker: LLD 14.0.0
>     [    14]  clang version 14.0.0 (Fedora 14.0.0-1.fc37)
>
>   $ llvm-readelf -h vdso{32,64}.so.dbg &| rg "(File|Entry point address):"
>   File: vdso32.so.dbg
>     Entry point address:               0x0
>   File: vdso64.so.dbg
>     Entry point address:               0x0
>
> Remove ENTRY to remove the warning, as it is unnecessary for the vDSO to
> function correctly.

Right, the vdso is going to be injected into the process' mappings;
what would it even mean for a DSO to have an entry point?
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
>  arch/powerpc/kernel/vdso/vdso32.lds.S | 1 -
>  arch/powerpc/kernel/vdso/vdso64.lds.S | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vdso/vdso32.lds.S b/arch/powerpc/kernel/vdso/vdso32.lds.S
> index 58e0099f70f4..e0d19d74455f 100644
> --- a/arch/powerpc/kernel/vdso/vdso32.lds.S
> +++ b/arch/powerpc/kernel/vdso/vdso32.lds.S
> @@ -13,7 +13,6 @@ OUTPUT_FORMAT("elf32-powerpcle", "elf32-powerpcle", "elf32-powerpcle")
>  OUTPUT_FORMAT("elf32-powerpc", "elf32-powerpc", "elf32-powerpc")
>  #endif
>  OUTPUT_ARCH(powerpc:common)
> -ENTRY(_start)
>
>  SECTIONS
>  {
> diff --git a/arch/powerpc/kernel/vdso/vdso64.lds.S b/arch/powerpc/kernel/vdso/vdso64.lds.S
> index 0288cad428b0..1a4a7bc4c815 100644
> --- a/arch/powerpc/kernel/vdso/vdso64.lds.S
> +++ b/arch/powerpc/kernel/vdso/vdso64.lds.S
> @@ -13,7 +13,6 @@ OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle")
>  OUTPUT_FORMAT("elf64-powerpc", "elf64-powerpc", "elf64-powerpc")
>  #endif
>  OUTPUT_ARCH(powerpc:common64)
> -ENTRY(_start)
>
>  SECTIONS
>  {
> --
> 2.36.1
>


-- 
Thanks,
~Nick Desaulniers

Re: [PATCH 1/2] powerpc/vdso: Remove unused ENTRY in linker scripts

[Alexey Kardashevskiy]

On 5/10/22 06:46, Nathan Chancellor wrote:
> When linking vdso{32,64}.so.dbg with ld.lld, there is a warning about
> not finding _start for the starting address:
> 
>    ld.lld: warning: cannot find entry symbol _start; not setting start address
>    ld.lld: warning: cannot find entry symbol _start; not setting start address
> 
> Looking at GCC + GNU ld, the entry point address is 0x0:
> 
>    $ llvm-readelf -h vdso{32,64}.so.dbg &| rg "(File|Entry point address):"
>    File: vdso32.so.dbg
>      Entry point address:               0x0
>    File: vdso64.so.dbg
>      Entry point address:               0x0
> 
> This matches what ld.lld emits:
> 
>    $ powerpc64le-linux-gnu-readelf -p .comment vdso{32,64}.so.dbg
> 
>    File: vdso32.so.dbg
> 
>    String dump of section '.comment':
>      [     0]  Linker: LLD 14.0.0
>      [    14]  clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> 
>    File: vdso64.so.dbg
> 
>    String dump of section '.comment':
>      [     0]  Linker: LLD 14.0.0
>      [    14]  clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> 
>    $ llvm-readelf -h vdso{32,64}.so.dbg &| rg "(File|Entry point address):"
>    File: vdso32.so.dbg
>      Entry point address:               0x0
>    File: vdso64.so.dbg
>      Entry point address:               0x0
> 
> Remove ENTRY to remove the warning, as it is unnecessary for the vDSO to
> function correctly.


Sounds more like a bugfix to me - _start is simply not defined, I wonder 
why ld is not complaining.


Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>


> 
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
>   arch/powerpc/kernel/vdso/vdso32.lds.S | 1 -
>   arch/powerpc/kernel/vdso/vdso64.lds.S | 1 -
>   2 files changed, 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/vdso/vdso32.lds.S b/arch/powerpc/kernel/vdso/vdso32.lds.S
> index 58e0099f70f4..e0d19d74455f 100644
> --- a/arch/powerpc/kernel/vdso/vdso32.lds.S
> +++ b/arch/powerpc/kernel/vdso/vdso32.lds.S
> @@ -13,7 +13,6 @@ OUTPUT_FORMAT("elf32-powerpcle", "elf32-powerpcle", "elf32-powerpcle")
>   OUTPUT_FORMAT("elf32-powerpc", "elf32-powerpc", "elf32-powerpc")
>   #endif
>   OUTPUT_ARCH(powerpc:common)
> -ENTRY(_start)
>   
>   SECTIONS
>   {
> diff --git a/arch/powerpc/kernel/vdso/vdso64.lds.S b/arch/powerpc/kernel/vdso/vdso64.lds.S
> index 0288cad428b0..1a4a7bc4c815 100644
> --- a/arch/powerpc/kernel/vdso/vdso64.lds.S
> +++ b/arch/powerpc/kernel/vdso/vdso64.lds.S
> @@ -13,7 +13,6 @@ OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle")
>   OUTPUT_FORMAT("elf64-powerpc", "elf64-powerpc", "elf64-powerpc")
>   #endif
>   OUTPUT_ARCH(powerpc:common64)
> -ENTRY(_start)
>   
>   SECTIONS
>   {

Re: [PATCH 1/2] powerpc/vdso: Remove unused ENTRY in linker scripts

[Fangrui Song]

On 2022-05-10, Alexey Kardashevskiy wrote:
>
>
>On 5/10/22 06:46, Nathan Chancellor wrote:
>>When linking vdso{32,64}.so.dbg with ld.lld, there is a warning about
>>not finding _start for the starting address:
>>
>>   ld.lld: warning: cannot find entry symbol _start; not setting start address
>>   ld.lld: warning: cannot find entry symbol _start; not setting start address
>>
>>Looking at GCC + GNU ld, the entry point address is 0x0:
>>
>>   $ llvm-readelf -h vdso{32,64}.so.dbg &| rg "(File|Entry point address):"
>>   File: vdso32.so.dbg
>>     Entry point address:               0x0
>>   File: vdso64.so.dbg
>>     Entry point address:               0x0
>>
>>This matches what ld.lld emits:
>>
>>   $ powerpc64le-linux-gnu-readelf -p .comment vdso{32,64}.so.dbg
>>
>>   File: vdso32.so.dbg
>>
>>   String dump of section '.comment':
>>     [     0]  Linker: LLD 14.0.0
>>     [    14]  clang version 14.0.0 (Fedora 14.0.0-1.fc37)
>>
>>   File: vdso64.so.dbg
>>
>>   String dump of section '.comment':
>>     [     0]  Linker: LLD 14.0.0
>>     [    14]  clang version 14.0.0 (Fedora 14.0.0-1.fc37)
>>
>>   $ llvm-readelf -h vdso{32,64}.so.dbg &| rg "(File|Entry point address):"
>>   File: vdso32.so.dbg
>>     Entry point address:               0x0
>>   File: vdso64.so.dbg
>>     Entry point address:               0x0
>>
>>Remove ENTRY to remove the warning, as it is unnecessary for the vDSO to
>>function correctly.

LGTM. e_entry for the vDSO (generally all shared objects, unless invoked
directly as the main executable) is unnecessary.

>Sounds more like a bugfix to me - _start is simply not defined, I 
>wonder why ld is not complaining.

This is a loose behavior in GNU ld. I know this but did not bother
filing a feature request.

Now that you mentioned it:) https://sourceware.org/bugzilla/show_bug.cgi?id=29136 (ld: ENTRY(no_such_symbol) in -shared mode does not report a warning)

>
>Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>
>
>>
>>Signed-off-by: Nathan Chancellor <nathan@kernel.org>
>>---
>>  arch/powerpc/kernel/vdso/vdso32.lds.S | 1 -
>>  arch/powerpc/kernel/vdso/vdso64.lds.S | 1 -
>>  2 files changed, 2 deletions(-)
>>
>>diff --git a/arch/powerpc/kernel/vdso/vdso32.lds.S b/arch/powerpc/kernel/vdso/vdso32.lds.S
>>index 58e0099f70f4..e0d19d74455f 100644
>>--- a/arch/powerpc/kernel/vdso/vdso32.lds.S
>>+++ b/arch/powerpc/kernel/vdso/vdso32.lds.S
>>@@ -13,7 +13,6 @@ OUTPUT_FORMAT("elf32-powerpcle", "elf32-powerpcle", "elf32-powerpcle")
>>  OUTPUT_FORMAT("elf32-powerpc", "elf32-powerpc", "elf32-powerpc")
>>  #endif
>>  OUTPUT_ARCH(powerpc:common)
>>-ENTRY(_start)
>>  SECTIONS
>>  {
>>diff --git a/arch/powerpc/kernel/vdso/vdso64.lds.S b/arch/powerpc/kernel/vdso/vdso64.lds.S
>>index 0288cad428b0..1a4a7bc4c815 100644
>>--- a/arch/powerpc/kernel/vdso/vdso64.lds.S
>>+++ b/arch/powerpc/kernel/vdso/vdso64.lds.S
>>@@ -13,7 +13,6 @@ OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle")
>>  OUTPUT_FORMAT("elf64-powerpc", "elf64-powerpc", "elf64-powerpc")
>>  #endif
>>  OUTPUT_ARCH(powerpc:common64)
>>-ENTRY(_start)
>>  SECTIONS
>>  {
>

[PATCH 2/2] powerpc/vdso: Link with ld.lld when requested

[Nathan Chancellor]

The PowerPC vDSO is linked with $(CC) instead of $(LD), which means the
default linker of the compiler is used instead of the linker requested
by the builder.

  $ make ARCH=powerpc LLVM=1 mrproper defconfig arch/powerpc/kernel/vdso/
  ...

  $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg

  File: arch/powerpc/kernel/vdso/vdso32.so.dbg
  String dump of section '.comment':
  [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)

  File: arch/powerpc/kernel/vdso/vdso64.so.dbg
  String dump of section '.comment':
  [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)

The compiler option '-fuse-ld' tells the compiler which linker to use
when it is invoked as both the compiler and linker. Use '-fuse-ld=lld'
when LD=ld.lld has been specified (CONFIG_LD_IS_LLD) so that the vDSO is
linked with the same linker as the rest of the kernel.

  $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg

  File: arch/powerpc/kernel/vdso/vdso32.so.dbg
  String dump of section '.comment':
  [     0] Linker: LLD 14.0.0
  [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)

  File: arch/powerpc/kernel/vdso/vdso64.so.dbg
  String dump of section '.comment':
  [     0] Linker: LLD 14.0.0
  [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)

LD can be a full path to ld.lld, which will not be handled properly by
'-fuse-ld=lld' if the full path to ld.lld is outside of the compiler's
search path. '-fuse-ld' can take a path to the linker but it is
deprecated in clang 12.0.0; '--ld-path' is preferred for this scenario.

Use '--ld-path' if it is supported, as it will handle a full path or
just 'ld.lld' properly. See the LLVM commit below for the full details
of '--ld-path'.

Link: https://github.com/ClangBuiltLinux/linux/issues/774
Link: https://github.com/llvm/llvm-project/commit/1bc5c84710a8c73ef21295e63c19d10a8c71f2f5
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/powerpc/kernel/vdso/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile
index 954974287ee7..096b0bf1335f 100644
--- a/arch/powerpc/kernel/vdso/Makefile
+++ b/arch/powerpc/kernel/vdso/Makefile
@@ -48,6 +48,7 @@ UBSAN_SANITIZE := n
 KASAN_SANITIZE := n
 
 ccflags-y := -shared -fno-common -fno-builtin -nostdlib -Wl,--hash-style=both
+ccflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld)
 
 CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32
 AS32FLAGS := -D__VDSO32__ -s
-- 
2.36.1

Re: [PATCH 2/2] powerpc/vdso: Link with ld.lld when requested

[Nick Desaulniers]

On Mon, May 9, 2022 at 1:47 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> The PowerPC vDSO is linked with $(CC) instead of $(LD), which means the
> default linker of the compiler is used instead of the linker requested
> by the builder.
>
>   $ make ARCH=powerpc LLVM=1 mrproper defconfig arch/powerpc/kernel/vdso/
>   ...
>
>   $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
>
>   File: arch/powerpc/kernel/vdso/vdso32.so.dbg
>   String dump of section '.comment':
>   [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
>
>   File: arch/powerpc/kernel/vdso/vdso64.so.dbg
>   String dump of section '.comment':
>   [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
>
> The compiler option '-fuse-ld' tells the compiler which linker to use
> when it is invoked as both the compiler and linker. Use '-fuse-ld=lld'
> when LD=ld.lld has been specified (CONFIG_LD_IS_LLD) so that the vDSO is
> linked with the same linker as the rest of the kernel.
>
>   $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
>
>   File: arch/powerpc/kernel/vdso/vdso32.so.dbg
>   String dump of section '.comment':
>   [     0] Linker: LLD 14.0.0
>   [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
>
>   File: arch/powerpc/kernel/vdso/vdso64.so.dbg
>   String dump of section '.comment':
>   [     0] Linker: LLD 14.0.0
>   [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
>
> LD can be a full path to ld.lld, which will not be handled properly by
> '-fuse-ld=lld' if the full path to ld.lld is outside of the compiler's
> search path. '-fuse-ld' can take a path to the linker but it is
> deprecated in clang 12.0.0; '--ld-path' is preferred for this scenario.
>
> Use '--ld-path' if it is supported, as it will handle a full path or
> just 'ld.lld' properly. See the LLVM commit below for the full details
> of '--ld-path'.

Perhaps worth adding some additional background from the cover letter
to the commit message that will actually go into the kernel,
particularly:
1. Kbuild mostly invokes the compiler and linker distinctly; the ppc
vdso code uses the compiler as the linker driver though.
2. When doing so, depending on how the compiler was configured, the
implicit default linker the compiler invokes might not match $LD.
3. This is a problem for LTO since clang may try to invoke ld.gold,
which is not supported as of
commit 75959d44f9dc ("kbuild: Fail if gold linker is detected")
4. Using the linker as the driver can cause ld.bfd 2.26 to crash.
https://lore.kernel.org/all/b2066ccd-2b81-6032-08e3-41105b400f75@csgroup.eu/
(Though, I wonder if that's because I was trying to add
--orphan-handling=warn, which we're not yet doing for the ppc vdso
AFAICT).

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

>
> Link: https://github.com/ClangBuiltLinux/linux/issues/774
> Link: https://github.com/llvm/llvm-project/commit/1bc5c84710a8c73ef21295e63c19d10a8c71f2f5
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
>  arch/powerpc/kernel/vdso/Makefile | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile
> index 954974287ee7..096b0bf1335f 100644
> --- a/arch/powerpc/kernel/vdso/Makefile
> +++ b/arch/powerpc/kernel/vdso/Makefile
> @@ -48,6 +48,7 @@ UBSAN_SANITIZE := n
>  KASAN_SANITIZE := n
>
>  ccflags-y := -shared -fno-common -fno-builtin -nostdlib -Wl,--hash-style=both
> +ccflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld)
>
>  CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32
>  AS32FLAGS := -D__VDSO32__ -s
> --
> 2.36.1
>


-- 
Thanks,
~Nick Desaulniers

Re: [PATCH 2/2] powerpc/vdso: Link with ld.lld when requested

[Nathan Chancellor]

On Mon, May 09, 2022 at 02:24:40PM -0700, Nick Desaulniers wrote:
> On Mon, May 9, 2022 at 1:47 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > The PowerPC vDSO is linked with $(CC) instead of $(LD), which means the
> > default linker of the compiler is used instead of the linker requested
> > by the builder.
> >
> >   $ make ARCH=powerpc LLVM=1 mrproper defconfig arch/powerpc/kernel/vdso/
> >   ...
> >
> >   $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
> >
> >   File: arch/powerpc/kernel/vdso/vdso32.so.dbg
> >   String dump of section '.comment':
> >   [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> >
> >   File: arch/powerpc/kernel/vdso/vdso64.so.dbg
> >   String dump of section '.comment':
> >   [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> >
> > The compiler option '-fuse-ld' tells the compiler which linker to use
> > when it is invoked as both the compiler and linker. Use '-fuse-ld=lld'
> > when LD=ld.lld has been specified (CONFIG_LD_IS_LLD) so that the vDSO is
> > linked with the same linker as the rest of the kernel.
> >
> >   $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
> >
> >   File: arch/powerpc/kernel/vdso/vdso32.so.dbg
> >   String dump of section '.comment':
> >   [     0] Linker: LLD 14.0.0
> >   [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> >
> >   File: arch/powerpc/kernel/vdso/vdso64.so.dbg
> >   String dump of section '.comment':
> >   [     0] Linker: LLD 14.0.0
> >   [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> >
> > LD can be a full path to ld.lld, which will not be handled properly by
> > '-fuse-ld=lld' if the full path to ld.lld is outside of the compiler's
> > search path. '-fuse-ld' can take a path to the linker but it is
> > deprecated in clang 12.0.0; '--ld-path' is preferred for this scenario.
> >
> > Use '--ld-path' if it is supported, as it will handle a full path or
> > just 'ld.lld' properly. See the LLVM commit below for the full details
> > of '--ld-path'.
> 
> Perhaps worth adding some additional background from the cover letter
> to the commit message that will actually go into the kernel,
> particularly:
> 1. Kbuild mostly invokes the compiler and linker distinctly; the ppc
> vdso code uses the compiler as the linker driver though.
> 2. When doing so, depending on how the compiler was configured, the
> implicit default linker the compiler invokes might not match $LD.

Sure, I think I can clear up these two points with something like:

"The PowerPC vDSO uses $(CC) to link, which differs from the rest of the
kernel, which uses $(LD) directly. As a result, the default linker of
the compiler is used, which may differ from the linker requested by the
builder. For example:

<example above>

LLVM=1 sets LD=ld.lld but ld.lld is not used to link the vDSO; GNU ld is
because "ld" is the default linker for clang on most Linux platforms."

Thoughts?

> 3. This is a problem for LTO since clang may try to invoke ld.gold,
> which is not supported as of
> commit 75959d44f9dc ("kbuild: Fail if gold linker is detected")

Technically, it seemed like ld.bfd was being invoked but the LLVMgold
plugin did not exist. Regardless, moving to ld.lld will resolve that,
since the LLVMgold plugin won't be needed.

> 4. Using the linker as the driver can cause ld.bfd 2.26 to crash.
> https://lore.kernel.org/all/b2066ccd-2b81-6032-08e3-41105b400f75@csgroup.eu/
> (Though, I wonder if that's because I was trying to add
> --orphan-handling=warn, which we're not yet doing for the ppc vdso
> AFAICT).

I can add this if necessary but it seemed like there might have been
other problems reported? I could just add a blanket "linker driver had
issues, we'll try again later" or something of that effect?

> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

Thank you for the review as always!

> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/774
> > Link: https://github.com/llvm/llvm-project/commit/1bc5c84710a8c73ef21295e63c19d10a8c71f2f5
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> >  arch/powerpc/kernel/vdso/Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile
> > index 954974287ee7..096b0bf1335f 100644
> > --- a/arch/powerpc/kernel/vdso/Makefile
> > +++ b/arch/powerpc/kernel/vdso/Makefile
> > @@ -48,6 +48,7 @@ UBSAN_SANITIZE := n
> >  KASAN_SANITIZE := n
> >
> >  ccflags-y := -shared -fno-common -fno-builtin -nostdlib -Wl,--hash-style=both
> > +ccflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld)
> >
> >  CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32
> >  AS32FLAGS := -D__VDSO32__ -s
> > --
> > 2.36.1
> >
> 
> 
> -- 
> Thanks,
> ~Nick Desaulniers

Re: [PATCH 2/2] powerpc/vdso: Link with ld.lld when requested

[Nick Desaulniers]

On Mon, May 9, 2022 at 2:47 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Mon, May 09, 2022 at 02:24:40PM -0700, Nick Desaulniers wrote:
> > On Mon, May 9, 2022 at 1:47 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > >
> > > The PowerPC vDSO is linked with $(CC) instead of $(LD), which means the
> > > default linker of the compiler is used instead of the linker requested
> > > by the builder.
> > >
> > >   $ make ARCH=powerpc LLVM=1 mrproper defconfig arch/powerpc/kernel/vdso/
> > >   ...
> > >
> > >   $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
> > >
> > >   File: arch/powerpc/kernel/vdso/vdso32.so.dbg
> > >   String dump of section '.comment':
> > >   [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > >
> > >   File: arch/powerpc/kernel/vdso/vdso64.so.dbg
> > >   String dump of section '.comment':
> > >   [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > >
> > > The compiler option '-fuse-ld' tells the compiler which linker to use
> > > when it is invoked as both the compiler and linker. Use '-fuse-ld=lld'
> > > when LD=ld.lld has been specified (CONFIG_LD_IS_LLD) so that the vDSO is
> > > linked with the same linker as the rest of the kernel.
> > >
> > >   $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
> > >
> > >   File: arch/powerpc/kernel/vdso/vdso32.so.dbg
> > >   String dump of section '.comment':
> > >   [     0] Linker: LLD 14.0.0
> > >   [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > >
> > >   File: arch/powerpc/kernel/vdso/vdso64.so.dbg
> > >   String dump of section '.comment':
> > >   [     0] Linker: LLD 14.0.0
> > >   [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > >
> > > LD can be a full path to ld.lld, which will not be handled properly by
> > > '-fuse-ld=lld' if the full path to ld.lld is outside of the compiler's
> > > search path. '-fuse-ld' can take a path to the linker but it is
> > > deprecated in clang 12.0.0; '--ld-path' is preferred for this scenario.
> > >
> > > Use '--ld-path' if it is supported, as it will handle a full path or
> > > just 'ld.lld' properly. See the LLVM commit below for the full details
> > > of '--ld-path'.
> >
> > Perhaps worth adding some additional background from the cover letter
> > to the commit message that will actually go into the kernel,
> > particularly:
> > 1. Kbuild mostly invokes the compiler and linker distinctly; the ppc
> > vdso code uses the compiler as the linker driver though.
> > 2. When doing so, depending on how the compiler was configured, the
> > implicit default linker the compiler invokes might not match $LD.
>
> Sure, I think I can clear up these two points with something like:
>
> "The PowerPC vDSO uses $(CC) to link, which differs from the rest of the
> kernel, which uses $(LD) directly. As a result, the default linker of
> the compiler is used, which may differ from the linker requested by the
> builder. For example:
>
> <example above>
>
> LLVM=1 sets LD=ld.lld but ld.lld is not used to link the vDSO; GNU ld is
> because "ld" is the default linker for clang on most Linux platforms."
>
> Thoughts?

SGTM

>
> > 3. This is a problem for LTO since clang may try to invoke ld.gold,
> > which is not supported as of
> > commit 75959d44f9dc ("kbuild: Fail if gold linker is detected")
>
> Technically, it seemed like ld.bfd was being invoked but the LLVMgold
> plugin did not exist. Regardless, moving to ld.lld will resolve that,
> since the LLVMgold plugin won't be needed.

Oh indeed, invoking clang with `-flto -###` shows it does invoke the
system's linker with `-plugin path/to/LLVMgold.so`, not `ld.gold`
itself.  I don't think we should use or depend on the LLVMgold.so
plugin either (I suspect it will invoke ld.gold, but as you noticed, I
don't bother to build LLVMgold.so).  So, perhaps reworded (feel free
to reword further):

3. This is a problem for LTO since clang may try to invoke ld.bfd with
the LLVMgold.so plugin.
https://llvm.org/docs/GoldPlugin.html states that "usage of the LLVM
gold plugin with ld.bfd is not tested and therefore not officially
supported or recommended." Users should instead use ld.lld to drive
linking for LTO with clang.

>
> > 4. Using the linker as the driver can cause ld.bfd 2.26 to crash.
> > https://lore.kernel.org/all/b2066ccd-2b81-6032-08e3-41105b400f75@csgroup.eu/
> > (Though, I wonder if that's because I was trying to add
> > --orphan-handling=warn, which we're not yet doing for the ppc vdso
> > AFAICT).
>
> I can add this if necessary but it seemed like there might have been
> other problems reported? I could just add a blanket "linker driver had
> issues, we'll try again later" or something of that effect?

Sure.

-- 
Thanks,
~Nick Desaulniers

Re: [PATCH 2/2] powerpc/vdso: Link with ld.lld when requested

[Nathan Chancellor]

On Mon, May 09, 2022 at 02:58:09PM -0700, Nick Desaulniers wrote:
> On Mon, May 9, 2022 at 2:47 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > On Mon, May 09, 2022 at 02:24:40PM -0700, Nick Desaulniers wrote:
> > > On Mon, May 9, 2022 at 1:47 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > > >
> > > > The PowerPC vDSO is linked with $(CC) instead of $(LD), which means the
> > > > default linker of the compiler is used instead of the linker requested
> > > > by the builder.
> > > >
> > > >   $ make ARCH=powerpc LLVM=1 mrproper defconfig arch/powerpc/kernel/vdso/
> > > >   ...
> > > >
> > > >   $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
> > > >
> > > >   File: arch/powerpc/kernel/vdso/vdso32.so.dbg
> > > >   String dump of section '.comment':
> > > >   [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > > >
> > > >   File: arch/powerpc/kernel/vdso/vdso64.so.dbg
> > > >   String dump of section '.comment':
> > > >   [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > > >
> > > > The compiler option '-fuse-ld' tells the compiler which linker to use
> > > > when it is invoked as both the compiler and linker. Use '-fuse-ld=lld'
> > > > when LD=ld.lld has been specified (CONFIG_LD_IS_LLD) so that the vDSO is
> > > > linked with the same linker as the rest of the kernel.
> > > >
> > > >   $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
> > > >
> > > >   File: arch/powerpc/kernel/vdso/vdso32.so.dbg
> > > >   String dump of section '.comment':
> > > >   [     0] Linker: LLD 14.0.0
> > > >   [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > > >
> > > >   File: arch/powerpc/kernel/vdso/vdso64.so.dbg
> > > >   String dump of section '.comment':
> > > >   [     0] Linker: LLD 14.0.0
> > > >   [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > > >
> > > > LD can be a full path to ld.lld, which will not be handled properly by
> > > > '-fuse-ld=lld' if the full path to ld.lld is outside of the compiler's
> > > > search path. '-fuse-ld' can take a path to the linker but it is
> > > > deprecated in clang 12.0.0; '--ld-path' is preferred for this scenario.
> > > >
> > > > Use '--ld-path' if it is supported, as it will handle a full path or
> > > > just 'ld.lld' properly. See the LLVM commit below for the full details
> > > > of '--ld-path'.
> > >
> > > Perhaps worth adding some additional background from the cover letter
> > > to the commit message that will actually go into the kernel,
> > > particularly:
> > > 1. Kbuild mostly invokes the compiler and linker distinctly; the ppc
> > > vdso code uses the compiler as the linker driver though.
> > > 2. When doing so, depending on how the compiler was configured, the
> > > implicit default linker the compiler invokes might not match $LD.
> >
> > Sure, I think I can clear up these two points with something like:
> >
> > "The PowerPC vDSO uses $(CC) to link, which differs from the rest of the
> > kernel, which uses $(LD) directly. As a result, the default linker of
> > the compiler is used, which may differ from the linker requested by the
> > builder. For example:
> >
> > <example above>
> >
> > LLVM=1 sets LD=ld.lld but ld.lld is not used to link the vDSO; GNU ld is
> > because "ld" is the default linker for clang on most Linux platforms."
> >
> > Thoughts?
> 
> SGTM
> 
> >
> > > 3. This is a problem for LTO since clang may try to invoke ld.gold,
> > > which is not supported as of
> > > commit 75959d44f9dc ("kbuild: Fail if gold linker is detected")
> >
> > Technically, it seemed like ld.bfd was being invoked but the LLVMgold
> > plugin did not exist. Regardless, moving to ld.lld will resolve that,
> > since the LLVMgold plugin won't be needed.
> 
> Oh indeed, invoking clang with `-flto -###` shows it does invoke the
> system's linker with `-plugin path/to/LLVMgold.so`, not `ld.gold`
> itself.  I don't think we should use or depend on the LLVMgold.so
> plugin either (I suspect it will invoke ld.gold, but as you noticed, I
> don't bother to build LLVMgold.so).  So, perhaps reworded (feel free
> to reword further):
> 
> 3. This is a problem for LTO since clang may try to invoke ld.bfd with
> the LLVMgold.so plugin.
> https://llvm.org/docs/GoldPlugin.html states that "usage of the LLVM
> gold plugin with ld.bfd is not tested and therefore not officially
> supported or recommended." Users should instead use ld.lld to drive
> linking for LTO with clang.

I'll stick this blurb above "The compiler option":

"This is a problem for Clang's Link Time Optimization as implemented in
the kernel because use of GNU ld with LTO requires the LLVMgold plugin,
which is not technically supported for ld.bfd per
https://llvm.org/docs/GoldPlugin.html. Furthermore, if LLVMgold.so is
missing from a user's system, the build will fail, even though LTO as it
is implemented in the kernel requires ld.lld to avoid this dependency in
the first place."

Yell if there is something I should change!

> > > 4. Using the linker as the driver can cause ld.bfd 2.26 to crash.
> > > https://lore.kernel.org/all/b2066ccd-2b81-6032-08e3-41105b400f75@csgroup.eu/
> > > (Though, I wonder if that's because I was trying to add
> > > --orphan-handling=warn, which we're not yet doing for the ppc vdso
> > > AFAICT).
> >
> > I can add this if necessary but it seemed like there might have been
> > other problems reported? I could just add a blanket "linker driver had
> > issues, we'll try again later" or something of that effect?
> 
> Sure.

Sounds good, I'll make these changes and send v2 on Wednesday to give
other folks a chance to chime in.

Cheers,
Nathan

Re: [PATCH 2/2] powerpc/vdso: Link with ld.lld when requested

[Alexey Kardashevskiy]

On 5/10/22 06:46, Nathan Chancellor wrote:
> The PowerPC vDSO is linked with $(CC) instead of $(LD), which means the
> default linker of the compiler is used instead of the linker requested
> by the builder.
> 
>    $ make ARCH=powerpc LLVM=1 mrproper defconfig arch/powerpc/kernel/vdso/
>    ...
> 
>    $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
> 
>    File: arch/powerpc/kernel/vdso/vdso32.so.dbg
>    String dump of section '.comment':
>    [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> 
>    File: arch/powerpc/kernel/vdso/vdso64.so.dbg
>    String dump of section '.comment':
>    [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> 
> The compiler option '-fuse-ld' tells the compiler which linker to use
> when it is invoked as both the compiler and linker. Use '-fuse-ld=lld'
> when LD=ld.lld has been specified (CONFIG_LD_IS_LLD) so that the vDSO is
> linked with the same linker as the rest of the kernel.
> 
>    $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
> 
>    File: arch/powerpc/kernel/vdso/vdso32.so.dbg
>    String dump of section '.comment':
>    [     0] Linker: LLD 14.0.0
>    [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> 
>    File: arch/powerpc/kernel/vdso/vdso64.so.dbg
>    String dump of section '.comment':
>    [     0] Linker: LLD 14.0.0
>    [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> 
> LD can be a full path to ld.lld, which will not be handled properly by
> '-fuse-ld=lld' if the full path to ld.lld is outside of the compiler's
> search path. '-fuse-ld' can take a path to the linker but it is
> deprecated in clang 12.0.0; '--ld-path' is preferred for this scenario.
> 
> Use '--ld-path' if it is supported, as it will handle a full path or
> just 'ld.lld' properly. See the LLVM commit below for the full details
> of '--ld-path'.
> 
> Link: https://github.com/ClangBuiltLinux/linux/issues/774
> Link: https://github.com/llvm/llvm-project/commit/1bc5c84710a8c73ef21295e63c19d10a8c71f2f5
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
>   arch/powerpc/kernel/vdso/Makefile | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile
> index 954974287ee7..096b0bf1335f 100644
> --- a/arch/powerpc/kernel/vdso/Makefile
> +++ b/arch/powerpc/kernel/vdso/Makefile
> @@ -48,6 +48,7 @@ UBSAN_SANITIZE := n
>   KASAN_SANITIZE := n
>   
>   ccflags-y := -shared -fno-common -fno-builtin -nostdlib -Wl,--hash-style=both
> +ccflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld)


Out of curiosity - how does this work exactly? I can see --ld-path= in 
the output so it works but there is no -fuse-ld=lld, is the second 
argument of cc-option only picked when the first one is not supported?

Anyway,

Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>



>   
>   CC32FLAGS := -Wl,-soname=linux-vdso32.so.1 -m32
>   AS32FLAGS := -D__VDSO32__ -s

Re: [PATCH 2/2] powerpc/vdso: Link with ld.lld when requested

[Nathan Chancellor]

On Tue, May 10, 2022 at 04:22:12PM +1000, Alexey Kardashevskiy wrote:
> 
> 
> On 5/10/22 06:46, Nathan Chancellor wrote:
> > The PowerPC vDSO is linked with $(CC) instead of $(LD), which means the
> > default linker of the compiler is used instead of the linker requested
> > by the builder.
> > 
> >    $ make ARCH=powerpc LLVM=1 mrproper defconfig arch/powerpc/kernel/vdso/
> >    ...
> > 
> >    $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
> > 
> >    File: arch/powerpc/kernel/vdso/vdso32.so.dbg
> >    String dump of section '.comment':
> >    [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > 
> >    File: arch/powerpc/kernel/vdso/vdso64.so.dbg
> >    String dump of section '.comment':
> >    [     0] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > 
> > The compiler option '-fuse-ld' tells the compiler which linker to use
> > when it is invoked as both the compiler and linker. Use '-fuse-ld=lld'
> > when LD=ld.lld has been specified (CONFIG_LD_IS_LLD) so that the vDSO is
> > linked with the same linker as the rest of the kernel.
> > 
> >    $ llvm-readelf -p .comment arch/powerpc/kernel/vdso/vdso{32,64}.so.dbg
> > 
> >    File: arch/powerpc/kernel/vdso/vdso32.so.dbg
> >    String dump of section '.comment':
> >    [     0] Linker: LLD 14.0.0
> >    [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > 
> >    File: arch/powerpc/kernel/vdso/vdso64.so.dbg
> >    String dump of section '.comment':
> >    [     0] Linker: LLD 14.0.0
> >    [    14] clang version 14.0.0 (Fedora 14.0.0-1.fc37)
> > 
> > LD can be a full path to ld.lld, which will not be handled properly by
> > '-fuse-ld=lld' if the full path to ld.lld is outside of the compiler's
> > search path. '-fuse-ld' can take a path to the linker but it is
> > deprecated in clang 12.0.0; '--ld-path' is preferred for this scenario.
> > 
> > Use '--ld-path' if it is supported, as it will handle a full path or
> > just 'ld.lld' properly. See the LLVM commit below for the full details
> > of '--ld-path'.
> > 
> > Link: https://github.com/ClangBuiltLinux/linux/issues/774
> > Link: https://github.com/llvm/llvm-project/commit/1bc5c84710a8c73ef21295e63c19d10a8c71f2f5
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> >   arch/powerpc/kernel/vdso/Makefile | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/powerpc/kernel/vdso/Makefile b/arch/powerpc/kernel/vdso/Makefile
> > index 954974287ee7..096b0bf1335f 100644
> > --- a/arch/powerpc/kernel/vdso/Makefile
> > +++ b/arch/powerpc/kernel/vdso/Makefile
> > @@ -48,6 +48,7 @@ UBSAN_SANITIZE := n
> >   KASAN_SANITIZE := n
> >   ccflags-y := -shared -fno-common -fno-builtin -nostdlib -Wl,--hash-style=both
> > +ccflags-$(CONFIG_LD_IS_LLD) += $(call cc-option,--ld-path=$(LD),-fuse-ld=lld)
> 
> 
> Out of curiosity - how does this work exactly? I can see --ld-path= in the
> output so it works but there is no -fuse-ld=lld, is the second argument of
> cc-option only picked when the first one is not supported?

Correct. See Documentation/kbuild/makefiles.rst for more information
about those macros if you are curious.

> Anyway,
> 
> Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Thanks a lot!

Cheers,
Nathan