remove cc-ldoption #342
Assignees
Labels
[BUG] linux
A bug that should be fixed in the mainline kernel.
[FIXED][LINUX] 5.2
This bug was fixed in Linux 5.2
[TOOL] lld
The issue is relevant to LLD linker
Comments
nickdesaulniers
added
[BUG] linux
|
Should be a fairly innocuous change to upstream as it isn't tied to upstreaming LTO support. At the same time though, do we actually need an diff --git a/Makefile b/Makefile
index 141653226f3c..5e9781490ea6 100644
--- a/Makefile
+++ b/Makefile
@@ -500,6 +500,9 @@ ifneq ($(GCC_TOOLCHAIN),)
CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN)
endif
CLANG_FLAGS += -no-integrated-as
+ifneq ($(shell $(LD) --version 2>&1 | head -n 1 | grep LLD),)
+CLANG_FLAGS += -fuse-ld=lld
+endif
KBUILD_CFLAGS += $(CLANG_FLAGS)
KBUILD_AFLAGS += $(CLANG_FLAGS)
export CLANG_FLAGSIf we do want to introduce something like |
|
Just FYI, the following diff builds and boots on arm64 in QEMU (I built with diff --git a/Makefile b/Makefile
index 18a02e4c611e..aa1d73084fe6 100644
--- a/Makefile
+++ b/Makefile
@@ -492,7 +492,7 @@ endif
ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),)
ifneq ($(CROSS_COMPILE),)
CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE:%-=%))
-GCC_TOOLCHAIN_DIR := $(dir $(shell which $(LD)))
+GCC_TOOLCHAIN_DIR := $(dir $(shell which $(AS)))
CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)
GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
endif
@@ -500,6 +500,10 @@ ifneq ($(GCC_TOOLCHAIN),)
CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN)
endif
CLANG_FLAGS += -no-integrated-as
+ifneq ($(shell $(LD) --version 2>&1 | head -n 1 | grep LLD),)
+CLANG_FLAGS += -fuse-ld=lld
+KBUILD_LDFLAGS += -O2
+endif
KBUILD_CFLAGS += $(CLANG_FLAGS)
KBUILD_AFLAGS += $(CLANG_FLAGS)
export CLANG_FLAGS
diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index b215c712d897..41a611256476 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -55,7 +55,7 @@ $(obj-vdso): %.o: %.S FORCE
# Actual build commands
quiet_cmd_vdsold = VDSOL $@
- cmd_vdsold = $(CC) $(c_flags) -Wl,-n -Wl,-T $^ -o $@
+ cmd_vdsold = $(CC) $(c_flags) -Wl,-N -Wl,-T $^ -o $@
quiet_cmd_vdsoas = VDSOA $@
cmd_vdsoas = $(CC) $(a_flags) -c -o $@ $<
|
|
@nathanchance , thanks for testing. If you stripped out the arm64 vdso stuff, I'd sign off on the Makefile change. I think there's more to do for arm64 vdso (both on the lld side, and maybe in that vdso's Makefile. If you could add those links to these separate issues, then give Rui (LLD maintainer) and I suggested by tags, that would be appreciated. Otherwise I will do so myself once I get back from FOSDEM/Brussels. |
|
I went ahead and tested arm32 as well, which now fails to build with I think something is goofy with Without that diff: With that diff: This particular error is coming from the lack of Line 67 in b23b0ea |
|
Ah great. You had similiar ideas and a use-case/test-case. Makes sense to distinguish on $LD_FOR_BUILD aka ld.bfd, ld.gold and ld.lld. |
|
https://lore.kernel.org/r/[email protected]/ Nathan, please file a separate bug for arm(32) vdso. |
This was referenced Feb 8, 2019
|
Also, handy trick from the LLD documentation for verifying if something was linked with LLD: |
kdrag0n
pushed a commit
to kdrag0n/proton_bluecross
that referenced
this issue
Feb 18, 2019
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
kdrag0n
pushed a commit
to kdrag0n/proton_bluecross
that referenced
this issue
Feb 18, 2019
Ripped from Nathan's patch on GitHub by kdrag0n: ClangBuiltLinux/linux#342 (comment) Signed-off-by: kdrag0n <[email protected]>
kdrag0n
pushed a commit
to kdrag0n/proton_bluecross
that referenced
this issue
Feb 18, 2019
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
kdrag0n
pushed a commit
to kdrag0n/proton_bluecross
that referenced
this issue
Feb 18, 2019
Ripped from Nathan's patch on GitHub by kdrag0n: ClangBuiltLinux/linux#342 (comment) Signed-off-by: kdrag0n <[email protected]>
kdrag0n
pushed a commit
to kdrag0n/proton_bluecross
that referenced
this issue
Feb 18, 2019
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
kdrag0n
pushed a commit
to kdrag0n/proton_bluecross
that referenced
this issue
Feb 18, 2019
Ripped from Nathan's patch on GitHub by kdrag0n: ClangBuiltLinux/linux#342 (comment) Signed-off-by: kdrag0n <[email protected]>
kdrag0n
pushed a commit
to kdrag0n/proton_bluecross
that referenced
this issue
Feb 20, 2019
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
kdrag0n
pushed a commit
to kdrag0n/proton_bluecross
that referenced
this issue
Feb 20, 2019
Ripped from Nathan's patch on GitHub by kdrag0n: ClangBuiltLinux/linux#342 (comment) Signed-off-by: kdrag0n <[email protected]>
kdrag0n
pushed a commit
to kdrag0n/proton_bluecross
that referenced
this issue
Feb 20, 2019
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
kdrag0n
pushed a commit
to kdrag0n/proton_bluecross
that referenced
this issue
Feb 20, 2019
Ripped from Nathan's patch on GitHub by kdrag0n: ClangBuiltLinux/linux#342 (comment) Signed-off-by: kdrag0n <[email protected]>
mawrick26
pushed a commit
to mawrick26/SDM845_P_9.0
that referenced
this issue
Feb 21, 2019
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Eliminater74 <[email protected]>
mawrick26
pushed a commit
to mawrick26/SDM845_P_9.0
that referenced
this issue
Feb 21, 2019
Ripped from Nathan's patch on GitHub by kdrag0n: ClangBuiltLinux/linux#342 (comment) Signed-off-by: kdrag0n <[email protected]> Signed-off-by: Eliminater74 <[email protected]>
duhansysl
added a commit
to duhansysl/exynos9810-kernel-V2
that referenced
this issue
Sep 30, 2024
* MAINTAINERS: add CLANG/LLVM BUILD SUPPORT info commit 8708e13c6a0600625eea3aebd027c0715a5d2bb2 upstream. Add keyword support so that our mailing list gets cc'ed for clang/llvm patches. We're pretty active on our mailing list so far as code review. There are numerous Googlers like myself that are paid to support building the Linux kernel with Clang and LLVM. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Nick Desaulniers <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Cc: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * Documentation/llvm: add documentation on building w/ Clang/LLVM commit fcf1b6a35c16ac500fa908a4022238e5d666eabf upstream. added to kbuild documentation. Provides more official info on building kernels with Clang and LLVM than our wiki. Suggested-by: Kees Cook <[email protected]> Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Sedat Dilek <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> [nd: hunk against Documentation/kbuild/index.rst dropped due to not backporting commit cd238effefa2 ("docs: kbuild: convert docs to ReST and rename to *.rst")] Signed-off-by: Greg Kroah-Hartman <[email protected]> * Documentation/llvm: fix the name of llvm-size commit 0f44fbc162b737ff6251ae248184390ae2279fee upstream. The tool is called llvm-size, not llvm-objsize. Fixes: fcf1b6a35c16 ("Documentation/llvm: add documentation on building w/ Clang/LLVM") Signed-off-by: Fangrui Song <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * kbuild: mark prepare0 as PHONY to fix external module build [ Upstream commit e00d8880481497474792d28c14479a9fb6752046 ] Commit c3ff2a5193fa ("powerpc/32: add stack protector support") caused kernel panic on PowerPC when an external module is used with CONFIG_STACKPROTECTOR because the 'prepare' target was not executed for the external module build. Commit e07db28eea38 ("kbuild: fix single target build for external module") turned it into a build error because the 'prepare' target is now executed but the 'prepare0' target is missing for the external module build. External module on arm/arm64 with CONFIG_STACKPROTECTOR_PER_TASK is also broken in the same way. Move 'PHONY += prepare0' to the common place. GNU Make is fine with missing rule for phony targets. I also removed the comment which is wrong irrespective of this commit. I minimize the change so it can be easily backported to 4.20.x To fix v4.20, please backport e07db28eea38 ("kbuild: fix single target build for external module"), and then this commit. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201891 Fixes: e07db28eea38 ("kbuild: fix single target build for external module") Fixes: c3ff2a5193fa ("powerpc/32: add stack protector support") Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries") Fixes: 0a1213fa7432 ("arm64: enable per-task stack canaries") Cc: linux-stable <[email protected]> # v4.20 Reported-by: Samuel Holland <[email protected]> Reported-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Tested-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Sasha Levin <[email protected]> * Makefile: remove CCACHE for now * kbuild: add OBJSIZE variable for the size tool commit 7bac98707f65b93bf994ef4e99b1eb9e7dbb9c32 upstream. Define and export OBJSIZE variable for "size" tool from binutils to be used in architecture specific Makefiles (naming the variable just "SIZE" would be too risky). In particular this tool is useful to perform checks that early boot code is not using bss section (which might have not been zeroed yet or intersects with initrd or other files boot loader might have put right after the linux kernel). Link: http://lkml.kernel.org/r/patch-1.thread-2257a1.git-188f5a3d81d5.your-ad-here.call-01565088755-ext-5120@work.hours Acked-by: Masahiro Yamada <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <[email protected]> * x86/boot: kbuild: allow readelf executable to be specified commit eefb8c124fd969e9a174ff2bedff86aa305a7438 upstream. Introduce a new READELF variable to top-level Makefile, so the name of readelf binary can be specified. Before this change the name of the binary was hardcoded to "$(CROSS_COMPILE)readelf" which might not be present for every toolchain. This allows to build with LLVM Object Reader by using make parameter READELF=llvm-readelf. Link: https://github.com/ClangBuiltLinux/linux/issues/771 Signed-off-by: Dmitry Golovin <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <[email protected]> * net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware commit 63b903dfebdea92aa92ad337d8451a6fbfeabf9d upstream. As far as I understood from the Kconfig help text, this build rule is used to rebuild the driver firmware, which runs on an old m68k-based chip. So, you need m68k tools for the firmware rebuild. wanxl.c is a PCI driver, but CONFIG_M68K does not select CONFIG_HAVE_PCI. So, you cannot enable CONFIG_WANXL_BUILD_FIRMWARE for ARCH=m68k. In other words, ifeq ($(ARCH),m68k) is false here. I am keeping the dead code for now, but rebuilding the firmware requires 'as68k' and 'ld68k', which I do not have in hand. Instead, the kernel.org m68k GCC [1] successfully built it. Allowing a user to pass in CROSS_COMPILE_M68K= is handier. [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/9.2.0/x86_64-gcc-9.2.0-nolibc-m68k-linux.tar.xz Suggested-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * net: wan: wanxl: use $(M68KCC) instead of $(M68KAS) for rebuilding firmware commit 734f3719d3438f9cc181d674c33ca9762e9148a1 upstream. The firmware source, wanxlfw.S, is currently compiled by the combo of $(CPP) and $(M68KAS). This is not what we usually do for compiling *.S files. In fact, this Makefile is the only user of $(AS) in the kernel build. Instead of combining $(CPP) and (AS) from different tool sets, using $(M68KCC) as an assembler driver is simpler, and saner. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * kbuild: remove AS variable commit aa824e0c962b532d5073cbb41b2efcd6f5e72bae upstream. As commit 5ef872636ca7 ("kbuild: get rid of misleading $(AS) from documents") noted, we rarely use $(AS) directly in the kernel build. Now that the only/last user of $(AS) in drivers/net/wan/Makefile was converted to $(CC), $(AS) is no longer used in the build process. You can still pass in AS=clang, which is just a switch to turn on the LLVM integrated assembler. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <[email protected]> * kbuild: replace AS=clang with LLVM_IAS=1 commit 7e20e47c70f810d678d02941fa3c671209c4ca97 upstream. The 'AS' variable is unused for building the kernel. Only the remaining usage is to turn on the integrated assembler. A boolean flag is a better fit for this purpose. AS=clang was added for experts. So, I replaced it with LLVM_IAS=1, breaking the backward compatibility. Suggested-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * kbuild: support LLVM=1 to switch the default tools to Clang/LLVM commit a0d1c951ef08ed24f35129267e3595d86f57f5d3 upstream. As Documentation/kbuild/llvm.rst implies, building the kernel with a full set of LLVM tools gets very verbose and unwieldy. Provide a single switch LLVM=1 to use Clang and LLVM tools instead of GCC and Binutils. You can pass it from the command line or as an environment variable. Please note LLVM=1 does not turn on the integrated assembler. You need to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the integrated assembler, I think we can make it default. We discussed what we need, and we agreed to go with a simple boolean flag that switches both target and host tools: https://lkml.org/lkml/2020/3/28/494 https://lkml.org/lkml/2020/4/3/43 Some items discussed, but not adopted: - LLVM_DIR When multiple versions of LLVM are installed, I just thought supporting LLVM_DIR=/path/to/my/llvm/bin/ might be useful. CC = $(LLVM_DIR)clang LD = $(LLVM_DIR)ld.lld ... However, we can handle this by modifying PATH. So, we decided to not do this. - LLVM_SUFFIX Some distributions (e.g. Debian) package specific versions of LLVM with naming conventions that use the version as a suffix. CC = clang$(LLVM_SUFFIX) LD = ld.lld(LLVM_SUFFIX) ... will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc., but the suffixed versions in /usr/bin/ are symlinks to binaries in /usr/lib/llvm-#/bin/, so this can also be handled by PATH. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> # build Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] [nd: hunk against Documentation/kbuild/kbuild.rst dropped due to not backporting commit cd238effefa2 ("docs: kbuild: convert docs to ReST and rename to *.rst")] Signed-off-by: Greg Kroah-Hartman <[email protected]> * FROMLIST: Kbuild: do not emit debug info for assembly with LLVM_IAS=1 Clang's integrated assembler produces the warning for assembly files: warning: DWARF2 only supports one section per compilation unit If -Wa,-gdwarf-* is unspecified, then debug info is not emitted for assembly sources (it is still emitted for C sources). This will be re-enabled for newer DWARF versions in a follow up patch. Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with LLVM=1 LLVM_IAS=1 for x86_64 and arm64. Reported-by: Dmitry Golovin <[email protected]> Reported-by: Nathan Chancellor <[email protected]> Suggested-by: Dmitry Golovin <[email protected]> Suggested-by: Nathan Chancellor <[email protected]> Suggested-by: Sedat Dilek <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Reviewed-by: Fangrui Song <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Cc: <[email protected]> Link: https://github.com/ClangBuiltLinux/linux/issues/716 Bug: 141693040 Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Nick Desaulniers <[email protected]> Change-Id: I55c8ad79dfeaae478c8de52d484e76fb2e37c194 * x86/lib: Change .weak to SYM_FUNC_START_WEAK for arch/x86/lib/mem*_64.S commit 4d6ffa27b8e5116c0abb318790fd01d4e12d75e6 upstream. Commit 393f203f5fd5 ("x86_64: kasan: add interceptors for memset/memmove/memcpy functions") added .weak directives to arch/x86/lib/mem*_64.S instead of changing the existing ENTRY macros to WEAK. This can lead to the assembly snippet .weak memcpy ... .globl memcpy which will produce a STB_WEAK memcpy with GNU as but STB_GLOBAL memcpy with LLVM's integrated assembler before LLVM 12. LLVM 12 (since https://reviews.llvm.org/D90108) will error on such an overridden symbol binding. Commit ef1e03152cb0 ("x86/asm: Make some functions local") changed ENTRY in arch/x86/lib/memcpy_64.S to SYM_FUNC_START_LOCAL, which was ineffective due to the preceding .weak directive. Use the appropriate SYM_FUNC_START_WEAK instead. Fixes: 393f203f5fd5 ("x86_64: kasan: add interceptors for memset/memmove/memcpy functions") Fixes: ef1e03152cb0 ("x86/asm: Make some functions local") Reported-by: Sami Tolvanen <[email protected]> Signed-off-by: Fangrui Song <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Cc: <[email protected]> Link: https://lkml.kernel.org/r/[email protected] [nd: backport due to missing commit e9b9d020c487 ("x86/asm: Annotate aliases") commit ffedeeb780dc ("linkage: Introduce new macros for assembler symbols")] Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * arm64: lse: fix LSE atomics with LLVM's integrated assembler commit e0d5896bd356cd577f9710a02d7a474cdf58426b upstream. Unlike gcc, clang considers each inline assembly block to be independent and therefore, when using the integrated assembler for inline assembly, any preambles that enable features must be repeated in each block. This change defines __LSE_PREAMBLE and adds it to each inline assembly block that has LSE instructions, which allows them to be compiled also with clang's assembler. Link: https://github.com/ClangBuiltLinux/linux/issues/671 Signed-off-by: Sami Tolvanen <[email protected]> Tested-by: Andrew Murray <[email protected]> Tested-by: Kees Cook <[email protected]> Reviewed-by: Andrew Murray <[email protected]> Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Will Deacon <[email protected]> [nd: backport adjusted due to missing: commit addfc38672c7 ("arm64: atomics: avoid out-of-line ll/sc atomics")] Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * Makefile: Move -Wno-unused-but-set-variable out of GCC only block commit 885480b084696331bea61a4f7eba10652999a9c1 upstream. Currently, -Wunused-but-set-variable is only supported by GCC so it is disabled unconditionally in a GCC only block (it is enabled with W=1). clang currently has its implementation for this warning in review so preemptively move this statement out of the GCC only block and wrap it with cc-disable-warning so that both compilers function the same. Cc: [email protected] Link: https://reviews.llvm.org/D100581 Signed-off-by: Nathan Chancellor <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> [nc: Backport, workaround lack of e2079e93f562 in older branches] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * fortify: Explicitly disable Clang support commit a52f8a59aef46b59753e583bf4b28fccb069ce64 upstream. Clang has never correctly compiled the FORTIFY_SOURCE defenses due to a couple bugs: Eliding inlines with matching __builtin_* names https://bugs.llvm.org/show_bug.cgi?id=50322 Incorrect __builtin_constant_p() of some globals https://bugs.llvm.org/show_bug.cgi?id=41459 In the process of making improvements to the FORTIFY_SOURCE defenses, the first (silent) bug (coincidentally) becomes worked around, but exposes the latter which breaks the build. As such, Clang must not be used with CONFIG_FORTIFY_SOURCE until at least latter bug is fixed (in Clang 13), and the fortify routines have been rearranged. Update the Kconfig to reflect the reality of the current situation. Signed-off-by: Kees Cook <[email protected]> Acked-by: Nick Desaulniers <[email protected]> Link: https://lore.kernel.org/lkml/CAKwvOd=A+ueGV2ihdy5GtgR2fQbcXjjAtVxv3=cPjffpebZB7A@mail.gmail.com Cc: Nathan Chancellor <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * Makefile.debug: re-enable debug info for .S files This is _not_ an upstream commit and just for 4.19.y only. It is based on commit 32ef9e5054ec0321b9336058c58ec749e9c6b0fe upstream. Alexey reported that the fraction of unknown filename instances in kallsyms grew from ~0.3% to ~10% recently; Bill and Greg tracked it down to assembler defined symbols, which regressed as a result of: commit b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1") In that commit, I allude to restoring debug info for assembler defined symbols in a follow up patch, but it seems I forgot to do so in commit a66049e2cf0e ("Kbuild: make DWARF version a choice") Fixes: b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1") Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * perf llvm: Return -ENOMEM when asprintf() fails [ Upstream commit c435c166dcf526ac827bc964d82cc0d5e7a1fd0b ] Zhihao sent a patch but it made llvm__compile_bpf() return what asprintf() returns on error, which is just -1, but since this function returns -errno, fix it by returning -ENOMEM for this case instead. Fixes: cb76371441d098 ("perf llvm: Allow passing options to llc ...") Fixes: 5eab5a7ee032ac ("perf llvm: Display eBPF compiling command ...") Reported-by: Hulk Robot <[email protected]> Reported-by: Zhihao Cheng <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Yu Kuai <[email protected]> Cc: [email protected] Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> * perf llvm: Fix inadvertent file creation [ Upstream commit 9f19aab47ced012eddef1e2bc96007efc7713b61 ] The LLVM template is first echo-ed into command_out and then command_out executed. The echo surrounds the template with double quotes, however, the template itself may contain quotes. This is generally innocuous but in tools/perf/tests/bpf-script-test-prologue.c we see: ... SEC("func=null_lseek file->f_mode offset orig") ... where the first double quote ends the double quote of the echo, then the > redirects output into a file called f_mode. To avoid this inadvertent behavior substitute redirects and similar characters to be ASCII control codes, then substitute the output in the echo back again. Fixes: 5eab5a7ee032acaa ("perf llvm: Display eBPF compiling command in debug output") Signed-off-by: Ian Rogers <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: [email protected] Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Tom Rix <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> * BACKPORT: arm64: Fix minor issues with the dcache_by_line_op macro [ Upstream commit 33309ecda0070506c49182530abe7728850ebe78 ] The dcache_by_line_op macro suffers from a couple of small problems: First, the GAS directives that are currently being used rely on assembler behavior that is not documented, and probably not guaranteed to produce the correct behavior going forward. As a result, we end up with some undefined symbols in cache.o: $ nm arch/arm64/mm/cache.o ... U civac ... U cvac U cvap U cvau This is due to the fact that the comparisons used to select the operation type in the dcache_by_line_op macro are comparing symbols not strings, and even though it seems that GAS is doing the right thing here (undefined symbols by the same name are equal to each other), it seems unwise to rely on this. Second, when patching in a DC CVAP instruction on CPUs that support it, the fallback path consists of a DC CVAU instruction which may be affected by CPU errata that require ARM64_WORKAROUND_CLEAN_CACHE. Solve these issues by unrolling the various maintenance routines and using the conditional directives that are documented as operating on strings. To avoid the complexity of nested alternatives, we move the DC CVAP patching to __clean_dcache_area_pop, falling back to a branch to __clean_dcache_area_poc if DCPOP is not supported by the CPU. Reported-by: Ard Biesheuvel <[email protected]> Suggested-by: Robin Murphy <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Change-Id: I006dd10a0f3706b9302832d04c65262861239709 * BACKPORT: crypto: arm64/aes-modes - get rid of literal load of addend vector commit ed6ed11830a9ded520db31a6e2b69b6b0a1eb0e2 upstream. Replace the literal load of the addend vector with a sequence that performs each add individually. This sequence is only 2 instructions longer than the original, and 2% faster on Cortex-A53. This is an improvement by itself, but also works around a Clang issue, whose integrated assembler does not implement the GNU ARM asm syntax completely, and does not support the =literal notation for FP registers (more info at https://bugs.llvm.org/show_bug.cgi?id=38642) Cc: Nick Desaulniers <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Change-Id: Ic8f7adcd28bd2da57b465a8e11e9d55b5669a539 * crypto: arm64/aes-ce-cipher - match round key endianness with generic code In order to be able to reuse the generic AES code as a fallback for situations where the NEON may not be used, update the key handling to match the byte order of the generic code: it stores round keys as sequences of 32-bit quantities rather than streams of bytes, and so our code needs to be updated to reflect that. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Change-Id: Ia5d6a7464a33240cafc544e79becd47018ecb703 * BACKPORT: crypto: arm64/aes-ce-cipher - move assembler code to .S file commit 019cd46984d04703a39924178f503a98436ac0d7 upstream. Most crypto drivers involving kernel mode NEON take care to put the code that actually touches the NEON register file in a separate compilation unit, to prevent the compiler from reordering code that preserves or restores the NEON context with code that may corrupt it. This is necessary because we currently have no way to express the restrictions imposed upon use of the NEON in kernel mode in a way that the compiler understands. However, in the case of aes-ce-cipher, it did not seem unreasonable to deviate from this rule, given how it does not seem possible for the compiler to reorder cross object function calls with asm blocks whose in- and output constraints reflect that it reads from and writes to memory. Now that LTO is being proposed for the arm64 kernel, it is time to revisit this. The link time optimization may replace the function calls to kernel_neon_begin() and kernel_neon_end() with instantiations of the IR that make up its implementation, allowing further reordering with the asm block. So let's clean this up, and move the asm() blocks into a separate .S file. Signed-off-by: Ard Biesheuvel <[email protected]> Reviewed-By: Nick Desaulniers <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Cc: Matthias Kaehlcke <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> [ bgcngm: Backported to 4.9 ] Signed-off-by: Bruno Martins <[email protected]> Change-Id: I7b271d83a3d5baf81aa5fca69cd4f2817945a477 * FROMLIST: Makefile: lld: tell clang to use lld This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Link: https://github.com/ClangBuiltLinux/linux/issues/342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]> Signed-off-by: Chenyang Zhong <[email protected]> * arm64: add endianness option to LDFLAGS instead of LD With the recent syntax extension, Kconfig is now able to evaluate the compiler / toolchain capability. However, accumulating flags to 'LD' is not compatible with the way it works; 'LD' must be passed to Kconfig to call $(ld-option,...) from Kconfig files. If you tweak 'LD' in arch Makefile depending on CONFIG_CPU_BIG_ENDIAN, this would end up with circular dependency between Makefile and Kconfig. Acked-by: Will Deacon <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Change-Id: I8a7654684975d45e979917e3b1c4b6249dec02ec * arm64: build with baremetal linker target instead of Linux when available Not all toolchains have the baremetal elf targets, RedHat/Fedora ones in particular. So, probe for whether it's available and use the previous (linux) targets if it isn't. Reported-by: Laura Abbott <[email protected]> Tested-by: Laura Abbott <[email protected]> Acked-by: Masahiro Yamada <[email protected]> Cc: Paul Kocialkowski <[email protected]> Signed-off-by: Olof Johansson <[email protected]> Signed-off-by: Will Deacon <[email protected]> Change-Id: Icf5462a8318b347cf11559c1654886c48c7a62b5 * FROMLIST: Makefile: lld: set -O2 linker flag when linking with LLD For arm64: 0.34% size improvement with lld -O2 over lld for vmlinux. 3.3% size improvement with lld -O2 over lld for Image.lz4-dtb. (am from https://lkml.org/lkml/2019/2/11/1949) Change-Id: Ibdc7ecc9861562305b49456d6d37274ce8075e22 Link: https://github.com/ClangBuiltLinux/linux/issues/343 Suggested-by: Rui Ueyama <[email protected]> Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]> Signed-off-by: Chenyang Zhong <[email protected]> * kbuild: clear LDFLAGS in the top Makefile The kernel needs to be compiled as a LP64 binary for ARM64, even when using a compiler that defaults to code-generation for the ILP32 ABI. Consequently, we need to explicitly pass '-mabi=lp64' (supported on gcc-4.9 and newer). Signed-off-by: Andrew Pinski <[email protected]> Signed-off-by: Philipp Tomsich <[email protected]> Signed-off-by: Christoph Muellner <[email protected]> Signed-off-by: Yury Norov <[email protected]> Reviewed-by: David Daney <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Change-Id: Ife00e01e3e3a6d85841b88c2f1a042617bd61500 * BACKPORT: arm64: Change .weak to SYM_FUNC_START_WEAK_PI for arch/arm64/lib/mem*.S commit ec9d78070de986ecf581ea204fd322af4d2477ec upstream. Commit 39d114ddc682 ("arm64: add KASAN support") added .weak directives to arch/arm64/lib/mem*.S instead of changing the existing SYM_FUNC_START_PI macros. This can lead to the assembly snippet `.weak memcpy ... .globl memcpy` which will produce a STB_WEAK memcpy with GNU as but STB_GLOBAL memcpy with LLVM's integrated assembler before LLVM 12. LLVM 12 (since https://reviews.llvm.org/D90108) will error on such an overridden symbol binding. Use the appropriate SYM_FUNC_START_WEAK_PI instead. Fixes: 39d114ddc682 ("arm64: add KASAN support") Reported-by: Sami Tolvanen <[email protected]> Signed-off-by: Fangrui Song <[email protected]> Tested-by: Sami Tolvanen <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> [nd: backport to adjust for missing: commit 3ac0f4526dfb ("arm64: lib: Use modern annotations for assembly functions") commit 35e61c77ef38 ("arm64: asm: Add new-style position independent function annotations")] Signed-off-by: Nick Desaulniers <[email protected]> Change-Id: Ibebbfa15f3337b5a2ac88ba683c5e429758d7a98 * arm64: relocatable: fix inconsistencies in linker script and options readelf complains about the section layout of vmlinux when building with CONFIG_RELOCATABLE=y (for KASLR): readelf: Warning: [21]: Link field (0) should index a symtab section. readelf: Warning: [21]: Info field (0) should index a relocatable section. Also, it seems that our use of '-pie -shared' is contradictory, and thus ambiguous. In general, the way KASLR is wired up at the moment is highly tailored to how ld.bfd happens to implement (and conflate) PIE executables and shared libraries, so given the current effort to support other toolchains, let's fix some of these issues as well. - Drop the -pie linker argument and just leave -shared. In ld.bfd, the differences between them are unclear (except for the ELF type of the produced image [0]) but lld chokes on seeing both at the same time. - Rename the .rela output section to .rela.dyn, as is customary for shared libraries and PIE executables, so that it is not misidentified by readelf as a static relocation section (producing the warnings above). - Pass the -z notext and -z norelro options to explicitly instruct the linker to permit text relocations, and to omit the RELRO program header (which requires a certain section layout that we don't adhere to in the kernel). These are the defaults for current versions of ld.bfd. - Discard .eh_frame and .gnu.hash sections to avoid them from being emitted between .head.text and .text, screwing up the section layout. These changes only affect the ELF image, and produce the same binary image. [0] b9dce7f1ba01 ("arm64: kernel: force ET_DYN ELF type for ...") Cc: Nick Desaulniers <[email protected]> Cc: Peter Smith <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]> * Makefile: Enable MLGO for register allocation This enables Machine Learning Guided Optimizations (MLGO) for register allocation. MLGO supported toolchain needed for that feature. * kbuild: Add support for LLVM's Polly optimizer This adds support for compiling the kernel with optimizations offered by LLVM's polyhedral loop optimizer known as Polly, which can improve performance by improving cache locality in loops. Note that LLVM is not compiled with Polly by default -- it must be enabled explicitly. Signed-off-by: halibw <[email protected]> * Makefile: llvm / poly optimize flags * Makefile: Exynos9810 mtunes * defconfig: set pstore compression to LZO-RLE This is optimized for zeroed memory also uses less cpu and fast * MAINTAINERS: add CLANG/LLVM BUILD SUPPORT info commit 8708e13c6a0600625eea3aebd027c0715a5d2bb2 upstream. Add keyword support so that our mailing list gets cc'ed for clang/llvm patches. We're pretty active on our mailing list so far as code review. There are numerous Googlers like myself that are paid to support building the Linux kernel with Clang and LLVM. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Nick Desaulniers <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Cc: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * Documentation/llvm: add documentation on building w/ Clang/LLVM commit fcf1b6a35c16ac500fa908a4022238e5d666eabf upstream. added to kbuild documentation. Provides more official info on building kernels with Clang and LLVM than our wiki. Suggested-by: Kees Cook <[email protected]> Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Sedat Dilek <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> [nd: hunk against Documentation/kbuild/index.rst dropped due to not backporting commit cd238effefa2 ("docs: kbuild: convert docs to ReST and rename to *.rst")] Signed-off-by: Greg Kroah-Hartman <[email protected]> * Documentation/llvm: fix the name of llvm-size commit 0f44fbc162b737ff6251ae248184390ae2279fee upstream. The tool is called llvm-size, not llvm-objsize. Fixes: fcf1b6a35c16 ("Documentation/llvm: add documentation on building w/ Clang/LLVM") Signed-off-by: Fangrui Song <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * kbuild: add OBJSIZE variable for the size tool commit 7bac98707f65b93bf994ef4e99b1eb9e7dbb9c32 upstream. Define and export OBJSIZE variable for "size" tool from binutils to be used in architecture specific Makefiles (naming the variable just "SIZE" would be too risky). In particular this tool is useful to perform checks that early boot code is not using bss section (which might have not been zeroed yet or intersects with initrd or other files boot loader might have put right after the linux kernel). Link: http://lkml.kernel.org/r/patch-1.thread-2257a1.git-188f5a3d81d5.your-ad-here.call-01565088755-ext-5120@work.hours Acked-by: Masahiro Yamada <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <[email protected]> * x86/boot: kbuild: allow readelf executable to be specified commit eefb8c124fd969e9a174ff2bedff86aa305a7438 upstream. Introduce a new READELF variable to top-level Makefile, so the name of readelf binary can be specified. Before this change the name of the binary was hardcoded to "$(CROSS_COMPILE)readelf" which might not be present for every toolchain. This allows to build with LLVM Object Reader by using make parameter READELF=llvm-readelf. Link: https://github.com/ClangBuiltLinux/linux/issues/771 Signed-off-by: Dmitry Golovin <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <[email protected]> * net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware commit 63b903dfebdea92aa92ad337d8451a6fbfeabf9d upstream. As far as I understood from the Kconfig help text, this build rule is used to rebuild the driver firmware, which runs on an old m68k-based chip. So, you need m68k tools for the firmware rebuild. wanxl.c is a PCI driver, but CONFIG_M68K does not select CONFIG_HAVE_PCI. So, you cannot enable CONFIG_WANXL_BUILD_FIRMWARE for ARCH=m68k. In other words, ifeq ($(ARCH),m68k) is false here. I am keeping the dead code for now, but rebuilding the firmware requires 'as68k' and 'ld68k', which I do not have in hand. Instead, the kernel.org m68k GCC [1] successfully built it. Allowing a user to pass in CROSS_COMPILE_M68K= is handier. [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/9.2.0/x86_64-gcc-9.2.0-nolibc-m68k-linux.tar.xz Suggested-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * net: wan: wanxl: use $(M68KCC) instead of $(M68KAS) for rebuilding firmware commit 734f3719d3438f9cc181d674c33ca9762e9148a1 upstream. The firmware source, wanxlfw.S, is currently compiled by the combo of $(CPP) and $(M68KAS). This is not what we usually do for compiling *.S files. In fact, this Makefile is the only user of $(AS) in the kernel build. Instead of combining $(CPP) and (AS) from different tool sets, using $(M68KCC) as an assembler driver is simpler, and saner. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * kbuild: remove AS variable commit aa824e0c962b532d5073cbb41b2efcd6f5e72bae upstream. As commit 5ef872636ca7 ("kbuild: get rid of misleading $(AS) from documents") noted, we rarely use $(AS) directly in the kernel build. Now that the only/last user of $(AS) in drivers/net/wan/Makefile was converted to $(CC), $(AS) is no longer used in the build process. You can still pass in AS=clang, which is just a switch to turn on the LLVM integrated assembler. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <[email protected]> * kbuild: replace AS=clang with LLVM_IAS=1 commit 7e20e47c70f810d678d02941fa3c671209c4ca97 upstream. The 'AS' variable is unused for building the kernel. Only the remaining usage is to turn on the integrated assembler. A boolean flag is a better fit for this purpose. AS=clang was added for experts. So, I replaced it with LLVM_IAS=1, breaking the backward compatibility. Suggested-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * kbuild: support LLVM=1 to switch the default tools to Clang/LLVM commit a0d1c951ef08ed24f35129267e3595d86f57f5d3 upstream. As Documentation/kbuild/llvm.rst implies, building the kernel with a full set of LLVM tools gets very verbose and unwieldy. Provide a single switch LLVM=1 to use Clang and LLVM tools instead of GCC and Binutils. You can pass it from the command line or as an environment variable. Please note LLVM=1 does not turn on the integrated assembler. You need to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the integrated assembler, I think we can make it default. We discussed what we need, and we agreed to go with a simple boolean flag that switches both target and host tools: https://lkml.org/lkml/2020/3/28/494 https://lkml.org/lkml/2020/4/3/43 Some items discussed, but not adopted: - LLVM_DIR When multiple versions of LLVM are installed, I just thought supporting LLVM_DIR=/path/to/my/llvm/bin/ might be useful. CC = $(LLVM_DIR)clang LD = $(LLVM_DIR)ld.lld ... However, we can handle this by modifying PATH. So, we decided to not do this. - LLVM_SUFFIX Some distributions (e.g. Debian) package specific versions of LLVM with naming conventions that use the version as a suffix. CC = clang$(LLVM_SUFFIX) LD = ld.lld(LLVM_SUFFIX) ... will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc., but the suffixed versions in /usr/bin/ are symlinks to binaries in /usr/lib/llvm-#/bin/, so this can also be handled by PATH. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> # build Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] [nd: hunk against Documentation/kbuild/kbuild.rst dropped due to not backporting commit cd238effefa2 ("docs: kbuild: convert docs to ReST and rename to *.rst")] Signed-off-by: Greg Kroah-Hartman <[email protected]> * FROMLIST: Kbuild: do not emit debug info for assembly with LLVM_IAS=1 Clang's integrated assembler produces the warning for assembly files: warning: DWARF2 only supports one section per compilation unit If -Wa,-gdwarf-* is unspecified, then debug info is not emitted for assembly sources (it is still emitted for C sources). This will be re-enabled for newer DWARF versions in a follow up patch. Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with LLVM=1 LLVM_IAS=1 for x86_64 and arm64. Reported-by: Dmitry Golovin <[email protected]> Reported-by: Nathan Chancellor <[email protected]> Suggested-by: Dmitry Golovin <[email protected]> Suggested-by: Nathan Chancellor <[email protected]> Suggested-by: Sedat Dilek <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Reviewed-by: Fangrui Song <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Cc: <[email protected]> Link: https://github.com/ClangBuiltLinux/linux/issues/716 Bug: 141693040 Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Nick Desaulniers <[email protected]> Change-Id: I55c8ad79dfeaae478c8de52d484e76fb2e37c194 * Makefile: Move -Wno-unused-but-set-variable out of GCC only block commit 885480b084696331bea61a4f7eba10652999a9c1 upstream. Currently, -Wunused-but-set-variable is only supported by GCC so it is disabled unconditionally in a GCC only block (it is enabled with W=1). clang currently has its implementation for this warning in review so preemptively move this statement out of the GCC only block and wrap it with cc-disable-warning so that both compilers function the same. Cc: [email protected] Link: https://reviews.llvm.org/D100581 Signed-off-by: Nathan Chancellor <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> [nc: Backport, workaround lack of e2079e93f562 in older branches] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * Makefile.debug: re-enable debug info for .S files This is _not_ an upstream commit and just for 4.19.y only. It is based on commit 32ef9e5054ec0321b9336058c58ec749e9c6b0fe upstream. Alexey reported that the fraction of unknown filename instances in kallsyms grew from ~0.3% to ~10% recently; Bill and Greg tracked it down to assembler defined symbols, which regressed as a result of: commit b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1") In that commit, I allude to restoring debug info for assembler defined symbols in a follow up patch, but it seems I forgot to do so in commit a66049e2cf0e ("Kbuild: make DWARF version a choice") Fixes: b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1") Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> * perf llvm: Return -ENOMEM when asprintf() fails [ Upstream commit c435c166dcf526ac827bc964d82cc0d5e7a1fd0b ] Zhihao sent a patch but it made llvm__compile_bpf() return what asprintf() returns on error, which is just -1, but since this function returns -errno, fix it by returning -ENOMEM for this case instead. Fixes: cb76371441d098 ("perf llvm: Allow passing options to llc ...") Fixes: 5eab5a7ee032ac ("perf llvm: Display eBPF compiling command ...") Reported-by: Hulk Robot <[email protected]> Reported-by: Zhihao Cheng <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Yu Kuai <[email protected]> Cc: [email protected] Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> * perf llvm: Fix inadvertent file creation [ Upstream commit 9f19aab47ced012eddef1e2bc96007efc7713b61 ] The LLVM template is first echo-ed into command_out and then command_out executed. The echo surrounds the template with double quotes, however, the template itself may contain quotes. This is generally innocuous but in tools/perf/tests/bpf-script-test-prologue.c we see: ... SEC("func=null_lseek file->f_mode offset orig") ... where the first double quote ends the double quote of the echo, then the > redirects output into a file called f_mode. To avoid this inadvertent behavior substitute redirects and similar characters to be ASCII control codes, then substitute the output in the echo back again. Fixes: 5eab5a7ee032acaa ("perf llvm: Display eBPF compiling command in debug output") Signed-off-by: Ian Rogers <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: [email protected] Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Tom Rix <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]> * arm64: add endianness option to LDFLAGS instead of LD With the recent syntax extension, Kconfig is now able to evaluate the compiler / toolchain capability. However, accumulating flags to 'LD' is not compatible with the way it works; 'LD' must be passed to Kconfig to call $(ld-option,...) from Kconfig files. If you tweak 'LD' in arch Makefile depending on CONFIG_CPU_BIG_ENDIAN, this would end up with circular dependency between Makefile and Kconfig. Acked-by: Will Deacon <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Catalin Marinas <[email protected]> Change-Id: I8a7654684975d45e979917e3b1c4b6249dec02ec * arm64: build with baremetal linker target instead of Linux when available Not all toolchains have the baremetal elf targets, RedHat/Fedora ones in particular. So, probe for whether it's available and use the previous (linux) targets if it isn't. Reported-by: Laura Abbott <[email protected]> Tested-by: Laura Abbott <[email protected]> Acked-by: Masahiro Yamada <[email protected]> Cc: Paul Kocialkowski <[email protected]> Signed-off-by: Olof Johansson <[email protected]> Signed-off-by: Will Deacon <[email protected]> Change-Id: Icf5462a8318b347cf11559c1654886c48c7a62b5 * FROMLIST: Makefile: lld: set -O2 linker flag when linking with LLD For arm64: 0.34% size improvement with lld -O2 over lld for vmlinux. 3.3% size improvement with lld -O2 over lld for Image.lz4-dtb. (am from https://lkml.org/lkml/2019/2/11/1949) Change-Id: Ibdc7ecc9861562305b49456d6d37274ce8075e22 Link: https://github.com/ClangBuiltLinux/linux/issues/343 Suggested-by: Rui Ueyama <[email protected]> Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]> Signed-off-by: Chenyang Zhong <[email protected]> * Makefile: Enable MLGO for register allocation This enables Machine Learning Guided Optimizations (MLGO) for register allocation. MLGO supported toolchain needed for that feature. * kbuild: Add support for LLVM's Polly optimizer This adds support for compiling the kernel with optimizations offered by LLVM's polyhedral loop optimizer known as Polly, which can improve performance by improving cache locality in loops. Note that LLVM is not compiled with Polly by default -- it must be enabled explicitly. Signed-off-by: halibw <[email protected]> * Makefile: Make CROSS_COMPILE optional Since our tree now supports LLVM_IAS there is no need for CROSS_COMPILE and gnu assembler, which was the only reason we needed gcc this makes the kernel compatible with latest aosp clang and simplifies the toolchain setup. ----------------------------------------------------------------------------------------- Before: make LLVM=1 LLVM__IAS=1 CROSS_COMPILE=aarch-linux-gnu CROSS_COMPILE_ARM32=arm-linux-gnueabi CLANG_TRIPLE=aarch-linux-gnu** After: make LLVM=1 ----------------------------------------------------------------------------------------- Moved Stuff to scripts/Makefile.clang , we do not modify the 4.14 too much to make it upstream friendly. Kanged Commits: GrapheneOS/kernel_gs@f0a6553 GrapheneOS/kernel_gs@26a2046 GrapheneOS/kernel_gs@37b9bb0 GrapheneOS/kernel_gs@3a260e9 GrapheneOS/kernel_gs@79bd0fe Signed-off-by: ghazzor <[email protected]> * Makefile: llvm / poly optimize flags * FROMLIST: Makefile: lld: set -O2 linker flag when linking with LLD For arm64: 0.34% size improvement with lld -O2 over lld for vmlinux. 3.3% size improvement with lld -O2 over lld for Image.lz4-dtb. (am from https://lkml.org/lkml/2019/2/11/1949) Change-Id: Ibdc7ecc9861562305b49456d6d37274ce8075e22 Link: https://github.com/ClangBuiltLinux/linux/issues/343 Suggested-by: Rui Ueyama <[email protected]> Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]> Signed-off-by: Chenyang Zhong <[email protected]> * kbuild: allow lld to be used with CONFIG_LTO_CLANG Bug: 63740206 Bug: 117299373 Change-Id: Ic9c8ca03fd082a8404905718f5312a3f497efa5a Signed-off-by: Sami Tolvanen <[email protected]> Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]> Signed-off-by: Chenyang Zhong <[email protected]> * Makefile: Globally disable compound-token-split-by-space warnings for Clang Signed-off-by: Adam W. Willis <[email protected]> Signed-off-by: Chenyang Zhong <[email protected]> * ANDROID: kbuild: limit LTO inlining This change limits function inlining across translation unit boundaries in order to reduce the binary size with LTO. The -import-instr-limit flag defines a size limit, as the number of LLVM IR instructions, for importing functions from other TUs. The default value is 100, and decreasing it to 5 reduces the size of a stripped arm64 defconfig vmlinux by 11%. Bug: 145297228 Bug: 140525226 Change-Id: Iaf366f843582972a5dfadc4695abb8f9c59882af Suggested-by: George Burgess IV <[email protected]> Signed-off-by: Sami Tolvanen <[email protected]> (cherry picked from commit 2ee80bf76d779d4ee3ef386774522208979d48ae) Signed-off-by: Kyle Lin <[email protected]> Signed-off-by: Chenyang Zhong <[email protected]> * ANDROID: kbuild: merge module sections with LTO LLD always splits sections with LTO, which increases module sizes. This change adds a linker script that merges the split sections in the final module. Bug: 145297228 Bug: 140525226 Change-Id: I247e8bd029bd0f98a4fa1cd4db7f6398467b8e55 Suggested-by: Nick Desaulniers <[email protected]> Signed-off-by: Sami Tolvanen <[email protected]> (cherry picked from commit 6cea04778e129512a395b5043864f79bd970c750) Signed-off-by: Kyle Lin <[email protected]> Signed-off-by: Chenyang Zhong <[email protected]> * ANDROID: kbuild: fix module linker script flags for LTO KBUILD_LDS_MODULE didn't exist in 4.19, it was added in upstream commit 10df06385582 ("kbuild: rebuild modules when module linker scripts are updated"), which means the module-lto.lds linker script is not actually passed to the linker. Append the flags directly to KBUILD_LDFLAGS_MODULE instead. Bug: 151700304 Fixes: 6cea04778e12 ("ANDROID: kbuild: merge module sections with LTO") Change-Id: I600db54d2ff9cd4e287913e8ddd463a20741a4a3 Signed-off-by: Sami Tolvanen <[email protected]> (cherry picked from commit 68fc81859b56f7e0dfb9e14021ace5c090eeec87) Signed-off-by: Chenyang Zhong <[email protected]> * Makefile: Set --lto-O3 LLD linker flag when building with clang LTO Signed-off-by: kdrag0n <[email protected]> Change-Id: I87faddd3bb5ca6e132ff3831bfddd2a0b4511fb9 Signed-off-by: Chenyang Zhong <[email protected]> * Revert "kbuild: disable clang's default use of -fmerge-all-constants" This reverts commit 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79. -fno-merge-all-constants has been the default since clang-6; the minimum supported version of clang in the kernel is clang-10 (10.0.1). Suggested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Tested-by: Sedat Dilek <[email protected]> Reviewed-by: Fangrui Song <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Sedat Dilek <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Marco Elver <[email protected]> Cc: Miguel Ojeda <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Vincenzo Frascino <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Link: https://reviews.llvm.org/rL329300. Link: https://github.com/ClangBuiltLinux/linux/issues/9 Signed-off-by: Linus Torvalds <[email protected]> * Makefile: evaluate LDFLAGS_BUILD_ID only once Evaluate LDFLAGS_BUILD_ID (which involves invoking the compiler) only once instead of over and over. This provides a ~20% reduction in null build time with x86 allnoconfig: $ make allnoconfig && make -j8 $ perf stat -r5 -e sched:sched_process_exec make -j8 - 2 119 sched:sched_process_exec + 1 878 sched:sched_process_exec - 1,238817018 seconds time elapsed + 0,971020553 seconds time elapsed Signed-off-by: Rabin Vincent <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> * kbuild: test --build-id linker flag by ld-option instead of cc-ldoption '--build-id' is passed to $(LD), so it should be tested by 'ld-option'. This seems a kind of misconversion when ld-option was renamed to cc-ldoption. Commit f86fd3066052 ("kbuild: rename ld-option to cc-ldoption") renamed all instances of 'ld-option' to 'cc-ldoption'. Then, commit 691ef3e7fdc1 ("kbuild: introduce ld-option") re-added 'ld-option' as a new implementation. Signed-off-by: Masahiro Yamada <[email protected]> * kbuild: Remove -Wno-format-invalid-specifier from clang block Turning on -Wformat does not reveal any instances of this warning across several different builds so remove this line to keep the number of disabled warnings as slim as possible. This has been disabled since commit 61163efae020 ("kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang"), which does not explain exactly why it was turned off but since it was so long ago in terms of both the kernel and LLVM so it is possible that some bug got fixed along the way. Signed-off-by: Nathan Chancellor <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> * ANDROID: scripts/Kbuild: avoid <<< for dash shell The build server seems to be using dash shell, which doesn't support <<<. Avoid invoking the shell entirely to figure out which linker we're using, so that we don't have bugs and build failures on the server that aren't reproducible locally. Bug: 117299373 Change-Id: I0cd9940c2fa07a6bb4573ec8b1edcd21fd1f3a4d Reported-by: Sami Tolvanen <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Rapherion Rollerscaperers <[email protected]> * ANDROID: modpost: filter function/data section ldflags The previous addition of -plugin-opt=-function-sections and -plugin-opt=-data-sections to LDFLAGS when performing LTO with gold was causing kernel modules to have individual sections for functions and data. This means that rather than having multiple symbols in the standard .text, .bss, and .data sections, there were now tens of thousands of sections, each with one symbol. This was problematic for third party tools used for parsing ramdumps that expect to find symbols in the standard object layout. This patch filters out these flags from LDFLAGS when constructing modules. Modules are linked in two phases with LTO. 1. produces <module>.lto.o 2. produces <module>.ko We must not use these flags during BOTH links otherwise these objects will have individual function and data sections. Running `readelf -S` on the above two files should show a number of sections in the order of tens (vs. tens of thousands) for the tooling to work properly. A more robust solution may be to look into is fixing the tooling to work with function and data section object layouts, but this should fix the tooling to work with the previous object layout for now. Bug: 116819139 Bug: 119467548 Bug: 120503084 Change-Id: I2a388f42d5e460654de9cbd0b37dae4463bbb73e Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Rapherion Rollerscaperers <[email protected]> * Fix build break for Argument list too long Reduce the number of files listed in the for loop statement in function update_lto_symversions to prevent error "Argument list too long" when building kernel in local workstation. Bug: 138277477 Test: Build pass Change-Id: I5218c60e6728f2425f3faa7f795c7782c5f817ad Signed-off-by: Hsiu-Chang Chen <[email protected]> * kbuild: rename LDFLAGS to KBUILD_LDFLAGS Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS. Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add additional options to AS") renamed AFLAGS to KBUILD_AFLAGS. Commit 06c5040cdb13 ("kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP") renamed CPPFLAGS to KBUILD_CPPFLAGS. For some reason, LDFLAGS was not renamed. Using a well-known variable like LDFLAGS may result in accidental override of the variable. Kbuild generally uses KBUILD_ prefixed variables for the internally appended options, so here is one more conversion to sanitize the naming convention. I did not touch Makefiles under tools/ since the tools build system is a different world. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Reviewed-by: Palmer Dabbelt <[email protected]> * Revert "Makefile: Set --lto-O3 LLD linker flag when building with clang LTO" This reverts commit afc9e253de92ac70bb8d4ffcc161126aa9c3d03b. It's not time to use the lto-O3 LLD linker flag ... aarch64-none-linux-gnu-ld: unrecognized option '--lto-O3' ... * Makefile: evaluate LDFLAGS_BUILD_ID only once Evaluate LDFLAGS_BUILD_ID (which involves invoking the compiler) only once instead of over and over. This provides a ~20% reduction in null build time with x86 allnoconfig: $ make allnoconfig && make -j8 $ perf stat -r5 -e sched:sched_process_exec make -j8 - 2 119 sched:sched_process_exec + 1 878 sched:sched_process_exec - 1,238817018 seconds time elapsed + 0,971020553 seconds time elapsed Signed-off-by: Rabin Vincent <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> * kbuild: test --build-id linker flag by ld-option instead of cc-ldoption '--build-id' is passed to $(LD), so it should be tested by 'ld-option'. This seems a kind of misconversion when ld-option was renamed to cc-ldoption. Commit f86fd3066052 ("kbuild: rename ld-option to cc-ldoption") renamed all instances of 'ld-option' to 'cc-ldoption'. Then, commit 691ef3e7fdc1 ("kbuild: introduce ld-option") re-added 'ld-opt…
duhansysl
pushed a commit
to duhansysl/exynos9810-kernel-V2
that referenced
this issue
Sep 30, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]> Signed-off-by: Chenyang Zhong <[email protected]>
duhansysl
pushed a commit
to duhansysl/exynos9810-kernel-V2
that referenced
this issue
Oct 1, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]> Signed-off-by: Chenyang Zhong <[email protected]>
duhansysl
pushed a commit
to duhansysl/exynos9810-kernel-V2
that referenced
this issue
Oct 5, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]> Signed-off-by: Chenyang Zhong <[email protected]>
ghost
pushed a commit
to Kurumi-Tokito/lineage_kernel_nokia_sdm660
that referenced
this issue
Oct 11, 2024
kbuild: Allow forcing the alternative LLD linker via Kconfig LLD is a relatively new linker from the LLVM Project that aims to be a faster and more modern alternative to the GNU gold and bfd linkers from binutils: https://lld.llvm.org/ I've also found that it offers more insightful diagnostics when something goes wrong, e.g. when there are undefined references. It does also appear to speed up the overall build time by 4-10s as compared to ld.bfd. These new config options will only allow fully-working configurations: - gold/lld when Clang LTO is enabled - bfd/lld otherwise Signed-off-by: Danny Lin <[email protected]> Signed-off-by: Adam W. Willis <[email protected]> Signed-off-by: Yaroslav Furman <[email protected]> BACKPORT: FROMLIST: Makefile: lld: set -O2 linker flag when linking w… …ith LLD For arm64: 0.34% size improvement with lld -O2 over lld for vmlinux. 3.3% size improvement with lld -O2 over lld for Image.lz4-dtb. Link: ClangBuiltLinux/linux#343 Suggested-by: Rui Ueyama <[email protected]> Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> (am from https://patchwork.kernel.org/patch/10806729/) Signed-off-by: Adam W. Willis <[email protected]> Signed-off-by: Yaroslav Furman <[email protected]> BACKPORT: FROMLIST: Makefile: lld: tell clang to use lld This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld={bfd,gold,lld,<absolute path to linker>}. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the BACKPORT: FROMLIST: Makefile: lld: tell clang to use lld This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld={bfd,gold,lld,<absolute path to linker>}. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. Select the linker via absolute path from $PATH via `which`. This allows you to build with: $ make LD=ld.lld $ make LD=ld.lld-8 $ make LD=/path/to/ld.lld Add -Qunused-arguments to KBUILD_CPPFLAGS sooner, as otherwise Clang likes to complain about -fuse-lld= being unused when compiling but not linking (-c) such as when cc-option is used. There's no need to guard with cc-option. Link: ClangBuiltLinux/linux#342 Link: ClangBuiltLinux/linux#366 Link: ClangBuiltLinux/linux#357 Suggested-by: Nathan Chancellor <[email protected]> Suggested-by: Masahiro Yamada <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Reviewed-by: Nathan Chancellor <natechancellor@gmail Signed-off-by: Divyanshu-Modi <[email protected]> Signed-off-by: Kunmun <[email protected]>
Hadenix
pushed a commit
to xiaomi-mt6765-devs/android_kernel_xiaomi_mt6765
that referenced
this issue
Oct 13, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Hadenix
pushed a commit
to xiaomi-mt6765-devs/android_kernel_xiaomi_mt6765
that referenced
this issue
Oct 16, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
MocaRafee
pushed a commit
to Mocaness/WhyredKernel
that referenced
this issue
Nov 9, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]>
MocaRafee
pushed a commit
to Mocaness/WhyredKernel
that referenced
this issue
Nov 9, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]>
MocaRafee
pushed a commit
to Mocaness/WhyredKernel
that referenced
this issue
Nov 9, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]>
MocaRafee
pushed a commit
to Mocaness/WhyredKernel
that referenced
this issue
Nov 9, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]>
MocaRafee
pushed a commit
to Mocaness/WhyredKernel
that referenced
this issue
Nov 9, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]>
k4ngcaribug
pushed a commit
to k4ngcaribug/kernel_xiaomi_ysl
that referenced
this issue
Nov 15, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Hadenix
pushed a commit
to xiaomi-mt6765-devs/android_kernel_xiaomi_mt6765
that referenced
this issue
Nov 22, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
log1cs
pushed a commit
to log1cs/msm-3.18
that referenced
this issue
Dec 6, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Signed-off-by: Yousef Algadri <[email protected]> Signed-off-by: Raphiel Rollerscaperers <[email protected]>
Huawei-Dev
pushed a commit
to Huawei-Dev/android_kernel_huawei_sydney
that referenced
this issue
Dec 17, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Huawei-Dev
pushed a commit
to Huawei-Dev/android_kernel_huawei_sydney
that referenced
this issue
Dec 18, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Hadenix
pushed a commit
to xiaomi-mt6765-devs/android_kernel_xiaomi_mt6765
that referenced
this issue
Dec 27, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Hadenix
pushed a commit
to xiaomi-mt6765-devs/android_kernel_xiaomi_mt6765
that referenced
this issue
Dec 27, 2024
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Huawei-Dev
pushed a commit
to Huawei-Dev/android_kernel_huawei_kirin710
that referenced
this issue
Jan 3, 2025
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Huawei-Dev
pushed a commit
to Huawei-Dev/android_kernel_huawei_kirin710
that referenced
this issue
Jan 3, 2025
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Huawei-Dev
pushed a commit
to Huawei-Dev/android_kernel_huawei_kirin710
that referenced
this issue
Jan 4, 2025
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Huawei-Dev
pushed a commit
to Huawei-Dev/android_kernel_huawei_kirin710
that referenced
this issue
Jan 4, 2025
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
eun0115
pushed a commit
to eun0115/android_kernel_samsung_wisdom
that referenced
this issue
Feb 3, 2025
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
eun0115
pushed a commit
to eun0115/android_kernel_samsung_wisdom
that referenced
this issue
Feb 3, 2025
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
eun0115
pushed a commit
to eun0115/android_kernel_samsung_wisdom
that referenced
this issue
Feb 3, 2025
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
ItsVixano
pushed a commit
to hisi-oss/android_kernel_huawei_hi3660
that referenced
this issue
Feb 6, 2025
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Huawei-Dev
pushed a commit
to Huawei-Dev/android_kernel_huawei_hi3660
that referenced
this issue
Feb 17, 2025
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Hadenix
pushed a commit
to xiaomi-mt6765-devs/android_kernel_xiaomi_mt6765
that referenced
this issue
Mar 3, 2025
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Hadenix
pushed a commit
to xiaomi-mt6765-devs/android_kernel_xiaomi_mt6765
that referenced
this issue
Mar 5, 2025
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Forked from: ClangBuiltLinux/continuous-integration#122
Some parts of the kernel invoke the linker via
$(CC)using-Wl,...flags. This is problematic because settingLD=ld.lldis not enough for this to work correctly.If compiling with Clang AND linking with LLD,
-fuse-ld=lldneeds to be added toKBUILD_CFLAGS.The pixel kernels have a
ld-namemacro to distinguish between bfd and gold. I've extended them to support lld, but seems the base patch is not upstreamed.cc @samitolvanen
The text was updated successfully, but these errors were encountered: