Patchwork [v3] kbuild: fix linker feature test macros when cross compiling with Clang

login
register
mail settings
Submitter Nick Desaulniers
Date Nov. 6, 2017, 6:47 p.m.
Message ID <20171106184756.24404-1-ndesaulniers@google.com>
Download mbox | patch
Permalink /patch/10044245/
State New
Headers show

Comments

Nick Desaulniers - Nov. 6, 2017, 6:47 p.m.
I was not seeing my linker flags getting added when using ld-option when
cross compiling with Clang. Upon investigation, this seems to be due to
a difference in how GCC vs Clang handle cross compilation.

GCC is configured at build time to support one backend, that is implicit
when compiling.  Clang is explicit via the use of `-target <triple>` and
ships with all supported backends by default.

GNU Make feature test macros that compile then link will always fail
when cross compiling with Clang unless Clang's triple is passed along to
the compiler. For example:

$ clang -x c /dev/null -c -o temp.o
$ aarch64-linux-android/bin/ld -E temp.o
aarch64-linux-android/bin/ld:
unknown architecture of input file `temp.o' is incompatible with
aarch64 output
aarch64-linux-android/bin/ld:
warning: cannot find entry symbol _start; defaulting to
0000000000400078
$ echo $?
1

$ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o
$ aarch64-linux-android/bin/ld -E temp.o
aarch64-linux-android/bin/ld:
warning: cannot find entry symbol _start; defaulting to 00000000004002e4
$ echo $?
0

This causes conditional checks that invoke $(CC) without the target
triple, then $(LD) on the result, to always fail.

Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
---
Changes since v2:
* Add LDFLAGS to ld-option, as per Masahiro, and spotted by 0-day bot:
  https://lists.01.org/pipermail/lkp/2017-October/007427.html

 scripts/Kbuild.include | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
Masahiro Yamada - Nov. 7, 2017, 3:41 a.m.
2017-11-07 3:47 GMT+09:00 Nick Desaulniers <ndesaulniers@google.com>:
> I was not seeing my linker flags getting added when using ld-option when
> cross compiling with Clang. Upon investigation, this seems to be due to
> a difference in how GCC vs Clang handle cross compilation.
>
> GCC is configured at build time to support one backend, that is implicit
> when compiling.  Clang is explicit via the use of `-target <triple>` and
> ships with all supported backends by default.
>
> GNU Make feature test macros that compile then link will always fail
> when cross compiling with Clang unless Clang's triple is passed along to
> the compiler. For example:
>
> $ clang -x c /dev/null -c -o temp.o
> $ aarch64-linux-android/bin/ld -E temp.o
> aarch64-linux-android/bin/ld:
> unknown architecture of input file `temp.o' is incompatible with
> aarch64 output
> aarch64-linux-android/bin/ld:
> warning: cannot find entry symbol _start; defaulting to
> 0000000000400078
> $ echo $?
> 1
>
> $ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o
> $ aarch64-linux-android/bin/ld -E temp.o
> aarch64-linux-android/bin/ld:
> warning: cannot find entry symbol _start; defaulting to 00000000004002e4
> $ echo $?
> 0
>
> This causes conditional checks that invoke $(CC) without the target
> triple, then $(LD) on the result, to always fail.
>
> Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> Changes since v2:
> * Add LDFLAGS to ld-option, as per Masahiro, and spotted by 0-day bot:
>   https://lists.01.org/pipermail/lkp/2017-October/007427.html
>
>  scripts/Kbuild.include | 5 +++--


Applied to linux-kbuild/kbuild.
Arnd Bergmann - Dec. 11, 2017, 10:17 a.m.
On Mon, Nov 6, 2017 at 7:47 PM, Nick Desaulniers
<ndesaulniers@google.com> wrote:
> I was not seeing my linker flags getting added when using ld-option when
> cross compiling with Clang. Upon investigation, this seems to be due to
> a difference in how GCC vs Clang handle cross compilation.
>
> GCC is configured at build time to support one backend, that is implicit
> when compiling.  Clang is explicit via the use of `-target <triple>` and
> ships with all supported backends by default.
>
> GNU Make feature test macros that compile then link will always fail
> when cross compiling with Clang unless Clang's triple is passed along to
> the compiler. For example:
>
> $ clang -x c /dev/null -c -o temp.o
> $ aarch64-linux-android/bin/ld -E temp.o
> aarch64-linux-android/bin/ld:
> unknown architecture of input file `temp.o' is incompatible with
> aarch64 output
> aarch64-linux-android/bin/ld:
> warning: cannot find entry symbol _start; defaulting to
> 0000000000400078
> $ echo $?
> 1
>
> $ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o
> $ aarch64-linux-android/bin/ld -E temp.o
> aarch64-linux-android/bin/ld:
> warning: cannot find entry symbol _start; defaulting to 00000000004002e4
> $ echo $?
> 0
>
> This causes conditional checks that invoke $(CC) without the target
> triple, then $(LD) on the result, to always fail.
>
> Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>

After this patch, I get the following warning in arm64 kernel builds
with CONFIG_ARM64_ERRATUM_843419:

arch/arm64/Makefile:27: ld does not support --fix-cortex-a53-843419;
kernel may be susceptible to erratum

This only happens on the first build though, when the cached variable
is being set. On the second build we get the contents from the cache
and the warning disappears.

I've tried debugging it further but did not get anywhere with that.

        Arnd
Masahiro Yamada - Dec. 11, 2017, 11:47 a.m.
2017-12-11 19:17 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> On Mon, Nov 6, 2017 at 7:47 PM, Nick Desaulniers
> <ndesaulniers@google.com> wrote:
>> I was not seeing my linker flags getting added when using ld-option when
>> cross compiling with Clang. Upon investigation, this seems to be due to
>> a difference in how GCC vs Clang handle cross compilation.
>>
>> GCC is configured at build time to support one backend, that is implicit
>> when compiling.  Clang is explicit via the use of `-target <triple>` and
>> ships with all supported backends by default.
>>
>> GNU Make feature test macros that compile then link will always fail
>> when cross compiling with Clang unless Clang's triple is passed along to
>> the compiler. For example:
>>
>> $ clang -x c /dev/null -c -o temp.o
>> $ aarch64-linux-android/bin/ld -E temp.o
>> aarch64-linux-android/bin/ld:
>> unknown architecture of input file `temp.o' is incompatible with
>> aarch64 output
>> aarch64-linux-android/bin/ld:
>> warning: cannot find entry symbol _start; defaulting to
>> 0000000000400078
>> $ echo $?
>> 1
>>
>> $ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o
>> $ aarch64-linux-android/bin/ld -E temp.o
>> aarch64-linux-android/bin/ld:
>> warning: cannot find entry symbol _start; defaulting to 00000000004002e4
>> $ echo $?
>> 0
>>
>> This causes conditional checks that invoke $(CC) without the target
>> triple, then $(LD) on the result, to always fail.
>>
>> Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
>> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
>
> After this patch, I get the following warning in arm64 kernel builds
> with CONFIG_ARM64_ERRATUM_843419:
>
> arch/arm64/Makefile:27: ld does not support --fix-cortex-a53-843419;
> kernel may be susceptible to erratum
>
> This only happens on the first build though, when the cached variable
> is being set. On the second build we get the contents from the cache
> and the warning disappears.
>
> I've tried debugging it further but did not get anywhere with that.
>
>         Arnd


Hmm.  I cannot reproduce this issue.



With Linaro 4.9 compiler,
I got "Detected assembler with broken .inst",
which is I think expected behavior.


With Linaro 7.2 compiler,
I did not get the warning,
which is also I think expected behavior.



$ make clean
  CLEAN   .
  CLEAN   .tmp_versions
$ make ARCH=arm64
CROSS_COMPILE=~/toolchains/aarch64-linaro-4.9/bin/aarch64-linux-gnu-
arch/arm64/Makefile:48: Detected assembler with broken .inst;
disassembly will be unreliable
  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/bin2c
  CC      kernel/bounds.s
  CHK     include/generated/bounds.h
  CHK     include/generated/timeconst.h
   ...

$ make ARCH=arm64
CROSS_COMPILE=~/toolchains/aarch64-linaro-7.2/bin/aarch64-linux-gnu-
  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CHK     include/generated/bounds.h
  CHK     include/generated/timeconst.h
  CHK     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  CHK     scripts/mod/devicetable-offsets.h
  CHK     include/generated/compile.h
    ...


Can you provide detailed steps to reproduce the problem?

Patch

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 064f477dfdca..be1c9d65eaf4 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -228,12 +228,13 @@  cc-if-fullversion = $(shell [ $(cc-fullversion) $(1) $(2) ] && echo $(3) || echo
 # cc-ldoption
 # Usage: ldflags += $(call cc-ldoption, -Wl$(comma)--hash-style=both)
 cc-ldoption = $(call try-run-cached,\
-	$(CC) $(1) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
+	$(CC) $(1) $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
 
 # ld-option
 # Usage: LDFLAGS += $(call ld-option, -X)
 ld-option = $(call try-run-cached,\
-	$(CC) -x c /dev/null -c -o "$$TMPO" ; $(LD) $(1) "$$TMPO" -o "$$TMP",$(1),$(2))
+	$(CC) $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -x c /dev/null -c -o "$$TMPO"; \
+	$(LD) $(LDFLAGS) $(1) "$$TMPO" -o "$$TMP",$(1),$(2))
 
 # ar-option
 # Usage: KBUILD_ARFLAGS := $(call ar-option,D)