Add support for Clang LTO

Move function tracer options to Kconfig to make it easier to add new methods for generating __mcount_loc, and to make the options available also when building kernel modules.

Note that FTRACE_MCOUNT_USE_* options are updated on rebuild and therefore, work even if the .config was generated in a different environment.

Signed-off-by Sami Tolvanen <[email protected]>

---

This change adds build system support for Clang's Link Time Optimization (LTO). With -flto, instead of ELF object files, Clang produces LLVM bitcode, which is compiled into native code at link time, allowing the final binary to be optimized globally. For more details, see:

https://llvm.org/docs/LinkTimeOptimization.html

The Kconfig option CONFIG_LTO_CLANG is implemented as a choice, which defaults to LTO being disabled. To use LTO, the architecture must select ARCH_SUPPORTS_LTO_CLANG and support:

- compiling with Clang,
- compiling inline assembly with Clang's integrated assembler,
- and linking with LLD.

While using full LTO results in the best runtime performance, the compilation is not scalable in time or memory. CONFIG_THINLTO enables ThinLTO, which allows parallel optimization and faster incremental builds. ThinLTO is used by default if the architecture also selects ARCH_SUPPORTS_THINLTO:

https://clang.llvm.org/docs/ThinLTO.html

To enable LTO, LLVM tools must be used to handle bitcode files. The easiest way is to pass the LLVM=1 option to make:

  $ make LLVM=1 defconfig
  $ scripts/config -e LTO_CLANG
  $ make LLVM=1

Alternatively, at least the following LLVM tools must be used:

CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm

To prepare for LTO support with other compilers, common parts are gated behind the CONFIG_LTO option, and LTO can be disabled for specific files by filtering out CC_FLAGS_LTO.

Signed-off-by Sami Tolvanen <[email protected]>

Reviewed-by Kees Cook <[email protected]>

---
 Makefile                          | 19 ++++++-
 arch/Kconfig                      | 88 +++++++++++++++++++++++++++++++
 include/asm-generic/vmlinux.lds.h | 11 ++--
 scripts/Makefile.build            |  9 +++-
 scripts/Makefile.modfinal         |  9 +++-
 scripts/Makefile.modpost          | 21 +++++++-
 scripts/link-vmlinux.sh           | 32 ++++++++---
 7 files changed, 171 insertions(+), 18 deletions(-)

Makefile +17 -2

index 16b7f0890e75..f5cac2428efc 100644
@@ -891,6 +891,21 @@ KBUILD_CFLAGS      += $(CC_FLAGS_SCS)
 export CC_FLAGS_SCS
 endif
 
+ifdef CONFIG_LTO_CLANG
+ifdef CONFIG_LTO_CLANG_THIN
+CC_FLAGS_LTO   += -flto=thin -fsplit-lto-unit
+KBUILD_LDFLAGS += --thinlto-cache-dir=$(extmod-prefix).thinlto-cache
+else
+CC_FLAGS_LTO   += -flto
+endif
+CC_FLAGS_LTO   += -fvisibility=default
+endif
+
+ifdef CONFIG_LTO
+KBUILD_CFLAGS  += $(CC_FLAGS_LTO)
+export CC_FLAGS_LTO
+endif
+
 ifdef CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_32B
 KBUILD_CFLAGS += -falign-functions=32
 endif

@@ -1471,7 +1486,7 @@ MRPROPER_FILES += include/config include/generated          \
                  *.spec
 
 # Directories & files removed with 'make distclean'
-DISTCLEAN_FILES += tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS
+DISTCLEAN_FILES += tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS .thinlto-cache
 
 # clean - Delete most, but leave enough to build external modules
 #

@@ -1717,7 +1732,7 @@ PHONY += compile_commands.json
 
 clean-dirs := $(KBUILD_EXTMOD)
 clean: rm-files := $(KBUILD_EXTMOD)/Module.symvers $(KBUILD_EXTMOD)/modules.nsdeps \
-       $(KBUILD_EXTMOD)/compile_commands.json
+       $(KBUILD_EXTMOD)/compile_commands.json $(KBUILD_EXTMOD)/.thinlto-cache
 
 PHONY += help
 help:

arch/Kconfig +60 -0

index 56b6ccc0e32d..30907b554451 100644
@@ -598,6 +598,94 @@ config SHADOW_CALL_STACK
          reading and writing arbitrary memory may be able to locate them
          and hijack control flow by modifying the stacks.
 
+config LTO
+       bool
+       help
+         Selected if the kernel will be built using the compiler's LTO feature.
+
+config LTO_CLANG
+       bool
+       select LTO
+       help
+         Selected if the kernel will be built using Clang's LTO feature.
+
+config ARCH_SUPPORTS_LTO_CLANG
+       bool
+       help
+         An architecture should select this option if it supports:
+         - compiling with Clang,
+         - compiling inline assembly with Clang's integrated assembler,
+         - and linking with LLD.
+
+config ARCH_SUPPORTS_LTO_CLANG_THIN
+       bool
+       help
+         An architecture should select this option if it can support Clang's
+         ThinLTO mode.
+
+config HAS_LTO_CLANG
+       def_bool y
+       # Clang >= 11: https://github.com/ClangBuiltLinux/linux/issues/510
+       depends on CC_IS_CLANG && CLANG_VERSION >= 110000 && LD_IS_LLD
+       depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
+       depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
+       depends on ARCH_SUPPORTS_LTO_CLANG
+       depends on !FTRACE_MCOUNT_USE_RECORDMCOUNT
+       depends on !KASAN
+       depends on !GCOV_KERNEL
+       depends on !MODVERSIONS
+       help
+         The compiler and Kconfig options support building with Clang's
+         LTO.
+
+choice
+       prompt "Link Time Optimization (LTO)"
+       default LTO_NONE
+       help
+         This option enables Link Time Optimization (LTO), which allows the
+         compiler to optimize binaries globally.
+
+         If unsure, select LTO_NONE. Note that LTO is very resource-intensive
+         so it's disabled by default.
+
+config LTO_NONE
+       bool "None"
+       help
+         Build the kernel normally, without Link Time Optimization (LTO).
+
+config LTO_CLANG_FULL
+       bool "Clang Full LTO (EXPERIMENTAL)"
+       depends on HAS_LTO_CLANG
+       select LTO_CLANG
+       help

This change adds build system support for Clang's Link Time Optimization (LTO). With -flto, instead of ELF object files, Clang produces LLVM bitcode, which is compiled into native code at link time, allowing the final binary to be optimized globally. For more details, see:

https://llvm.org/docs/LinkTimeOptimization.html

The Kconfig option CONFIG_LTO_CLANG is implemented as a choice, which defaults to LTO being disabled. To use LTO, the architecture must select ARCH_SUPPORTS_LTO_CLANG and support:

- compiling with Clang,
- compiling inline assembly with Clang's integrated assembler,
- and linking with LLD.

While using full LTO results in the best runtime performance, the compilation is not scalable in time or memory. CONFIG_THINLTO enables ThinLTO, which allows parallel optimization and faster incremental builds. ThinLTO is used by default if the architecture also selects ARCH_SUPPORTS_THINLTO:

https://clang.llvm.org/docs/ThinLTO.html

To enable LTO, LLVM tools must be used to handle bitcode files. The easiest way is to pass the LLVM=1 option to make:

  $ make LLVM=1 defconfig
  $ scripts/config -e LTO_CLANG
  $ make LLVM=1

Alternatively, at least the following LLVM tools must be used:

CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm

To prepare for LTO support with other compilers, common parts are gated behind the CONFIG_LTO option, and LTO can be disabled for specific files by filtering out CC_FLAGS_LTO.

Signed-off-by Sami Tolvanen <[email protected]>

Reviewed-by Kees Cook <[email protected]>

This patch series adds support for building the kernel with Clang's Link Time Optimization (LTO). In addition to performance, the primary motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to be used in the kernel. Google has shipped millions of Pixel devices running three major kernel versions with LTO+CFI since 2018.

Most of the patches are build system changes for handling LLVM bitcode, which Clang produces with LTO instead of ELF object files, postponing ELF processing until a later stage, and ensuring initcall ordering.

Note that arm64 support depends on Will's memory ordering patches [1]. I will post x86_64 patches separately after we have fixed the remaining objtool warnings [2][3].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/lto
[2] https://lore.kernel.org/lkml/20201120040424.a3wctajzft4ufoiw@treble/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool-vmlinux

You can also pull this series from

https://github.com/samitolvanen/linux.git lto-v8

---
Changes in v8:

- Cleaned up the LTO Kconfig options based on suggestions from Nick and Kees.

This patch series adds support for building the kernel with Clang's Link Time Optimization (LTO). In addition to performance, the primary motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to be used in the kernel. Google has shipped millions of Pixel devices running three major kernel versions with LTO+CFI since 2018.

Most of the patches are build system changes for handling LLVM bitcode, which Clang produces with LTO instead of ELF object files, postponing ELF processing until a later stage, and ensuring initcall ordering.

Note that arm64 support depends on Will's memory ordering patches [1]. I will post x86_64 patches separately after we have fixed the remaining objtool warnings [2][3].

Hi Sami,

Quoted 11 lines · Sami Tolvanen

This patch series adds support for building the kernel with Clang's Link Time Optimization (LTO). In addition to performance, the primary motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to be used in the kernel. Google has shipped millions of Pixel devices running three major kernel versions with LTO+CFI since 2018.

Most of the patches are build system changes for handling LLVM bitcode, which Clang produces with LTO instead of ELF object files, postponing ELF processing until a later stage, and ensuring initcall ordering.

Quoted 3 lines

Note that arm64 support depends on Will's memory ordering patches [1]. I will post x86_64 patches separately after we have fixed the remaining objtool warnings [2][3].

I took this series for a spin, with my for-next/lto branch merged in but I see a failure during the LTO stage with clang 11.0.5 because it doesn't understand the '.arch_extension rcpc' directive we throw out in READ_ONCE().

We actually check that this extension is available before using it in the arm64 Kconfig:

        config AS_HAS_LDAPR
                def_bool $(as-instr,.arch_extension rcpc)

so this shouldn't happen. I then realised, I wasn't passing LLVM_IAS=1 on my Make command line; with that, then the detection works correctly and the LTO step succeeds.

Why is it necessary to pass LLVM_IAS=1 if LTO is enabled? I think it would be _much_ better if this was implicit (or if LTO depended on it).

Quoted 15 lines · Will Deacon

Hi Sami,

Quoted 11 lines · Sami Tolvanen

This patch series adds support for building the kernel with Clang's Link Time Optimization (LTO). In addition to performance, the primary motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to be used in the kernel. Google has shipped millions of Pixel devices running three major kernel versions with LTO+CFI since 2018.

Most of the patches are build system changes for handling LLVM bitcode, which Clang produces with LTO instead of ELF object files, postponing ELF processing until a later stage, and ensuring initcall ordering.

Quoted 7 lines

Quoted 3 lines

Note that arm64 support depends on Will's memory ordering patches [1]. I will post x86_64 patches separately after we have fixed the remaining objtool warnings [2][3].

I took this series for a spin, with my for-next/lto branch merged in but I see a failure during the LTO stage with clang 11.0.5 because it doesn't understand the '.arch_extension rcpc' directive we throw out in READ_ONCE().

I just tested this with Clang 11.0.0, which I believe is the latest 11.x version, and the current Clang 12 development branch, and both work for me. Godbolt confirms that '.arch_extension rcpc' is supported by the integrated assembler starting with Clang 11 (the example fails with 10.0.1):

https://godbolt.org/z/1csGcT

What does running clang --version and ld.lld --version tell you?

Quoted 6 lines

We actually check that this extension is available before using it in the arm64 Kconfig:

        config AS_HAS_LDAPR
                def_bool $(as-instr,.arch_extension rcpc)

Quoted 6 lines

so this shouldn't happen. I then realised, I wasn't passing LLVM_IAS=1 on my Make command line; with that, then the detection works correctly and the LTO step succeeds.

Why is it necessary to pass LLVM_IAS=1 if LTO is enabled? I think it would be _much_ better if this was implicit (or if LTO depended on it).

Without LLVM_IAS=1, Clang uses two different assemblers when LTO is
enabled: the external GNU assembler for stand-alone assembly, and LLVM's integrated assembler for inline assembly. as-instr tests the external assembler and makes an admittedly reasonable assumption that the test is also valid for inline assembly.

I agree that it would reduce confusion in future if we just always enabled IAS with LTO. Nick, Nathan, any thoughts about this?

Quoted 12 lines · Will Deacon

Quoted 11 lines · Sami Tolvanen

This patch series adds support for building the kernel with Clang's Link Time Optimization (LTO). In addition to performance, the primary motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to be used in the kernel. Google has shipped millions of Pixel devices running three major kernel versions with LTO+CFI since 2018.

Most of the patches are build system changes for handling LLVM bitcode, which Clang produces with LTO instead of ELF object files, postponing ELF processing until a later stage, and ensuring initcall ordering.

Quoted 7 lines

Quoted 3 lines

Note that arm64 support depends on Will's memory ordering patches [1]. I will post x86_64 patches separately after we have fixed the remaining objtool warnings [2][3].

I took this series for a spin, with my for-next/lto branch merged in but I see a failure during the LTO stage with clang 11.0.5 because it doesn't understand the '.arch_extension rcpc' directive we throw out in READ_ONCE().

I just tested this with Clang 11.0.0, which I believe is the latest 11.x version, and the current Clang 12 development branch, and both work for me. Godbolt confirms that '.arch_extension rcpc' is supported by the integrated assembler starting with Clang 11 (the example fails with 10.0.1):

https://godbolt.org/z/1csGcT

What does running clang --version and ld.lld --version tell you?

Quoted 6 lines

We actually check that this extension is available before using it in the arm64 Kconfig:

        config AS_HAS_LDAPR
                def_bool $(as-instr,.arch_extension rcpc)

Quoted 6 lines

so this shouldn't happen. I then realised, I wasn't passing LLVM_IAS=1 on my Make command line; with that, then the detection works correctly and the LTO step succeeds.

Why is it necessary to pass LLVM_IAS=1 if LTO is enabled? I think it would be _much_ better if this was implicit (or if LTO depended on it).

Without LLVM_IAS=1, Clang uses two different assemblers when LTO is
enabled: the external GNU assembler for stand-alone assembly, and LLVM's integrated assembler for inline assembly. as-instr tests the external assembler and makes an admittedly reasonable assumption that the test is also valid for inline assembly.

I agree that it would reduce confusion in future if we just always enabled IAS with LTO. Nick, Nathan, any thoughts about this?

Quoted 11 lines · Sami Tolvanen

Quoted 3 lines · Will Deacon

I took this series for a spin, with my for-next/lto branch merged in but I see a failure during the LTO stage with clang 11.0.5 because it doesn't understand the '.arch_extension rcpc' directive we throw out in READ_ONCE().

I just tested this with Clang 11.0.0, which I believe is the latest 11.x version, and the current Clang 12 development branch, and both work for me. Godbolt confirms that '.arch_extension rcpc' is supported by the integrated assembler starting with Clang 11 (the example fails with 10.0.1):

Quoted 3 lines

https://godbolt.org/z/1csGcT

What does running clang --version and ld.lld --version tell you?

I'm using some Android prebuilts I had kicking around:

Android (6875598, based on r399163b) clang version 11.0.5 (https://android.googlesource.com/toolchain/llvm-project 87f1315dfbea7c137aa2e6d362dbb457e388158d)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/google/home/willdeacon/work/android/repo/android-kernel/prebuilts-master/clang/host/linux-x86/clang-r399163b/bin

and:

LLD 11.0.5 (/buildbot/tmp/tmpx1DlI_ 87f1315dfbea7c137aa2e6d362dbb457e388158d) (compatible with GNU linkers)

11.0.5 is AOSP's clang, which is behind the upstream 11.0.0 release so it is most likely the case that it is missing the patch that added rcpc. I think that a version based on the development branch (12.0.0) is in the works but I am not sure.

Quoted 19 lines

Quoted 6 lines

We actually check that this extension is available before using it in the arm64 Kconfig:

        config AS_HAS_LDAPR
                def_bool $(as-instr,.arch_extension rcpc)

Quoted 6 lines

so this shouldn't happen. I then realised, I wasn't passing LLVM_IAS=1 on my Make command line; with that, then the detection works correctly and the LTO step succeeds.

Why is it necessary to pass LLVM_IAS=1 if LTO is enabled? I think it would be _much_ better if this was implicit (or if LTO depended on it).

Without LLVM_IAS=1, Clang uses two different assemblers when LTO is
enabled: the external GNU assembler for stand-alone assembly, and LLVM's integrated assembler for inline assembly. as-instr tests the external assembler and makes an admittedly reasonable assumption that the test is also valid for inline assembly.

Quoted 2 lines

I agree that it would reduce confusion in future if we just always enabled IAS with LTO. Nick, Nathan, any thoughts about this?

That works for me, although I'm happy with anything which means that the assembler checks via as-instr apply to the assembler which will ultimately be used.

Quoted 7 lines · Will Deacon

Quoted 6 lines · Sami Tolvanen

Without LLVM_IAS=1, Clang uses two different assemblers when LTO is
enabled: the external GNU assembler for stand-alone assembly, and LLVM's integrated assembler for inline assembly. as-instr tests the external assembler and makes an admittedly reasonable assumption that the test is also valid for inline assembly.

Quoted 6 lines

Quoted 2 lines

I agree that it would reduce confusion in future if we just always enabled IAS with LTO. Nick, Nathan, any thoughts about this?

That works for me, although I'm happy with anything which means that the assembler checks via as-instr apply to the assembler which will ultimately be used.

I agree with Will.

So I'd recommend to Sami to simply make the Kconfig also depend on clang's integrated assembler (not just llvm-nm and llvm-ar). If someone cares about LTO with Clang as the compiler but GAS as the assembler, then we can revisit supporting that combination (and the changes to KCONFIG), but it shouldn't be something we consider Tier 1 supported or a combination that need be supported in a minimum viable product. And at that point we should make it avoid clang's integrated assembler entirely (I suspect LTO won't work at all in that case, so maybe even considering it is a waste of time).

One question I have to Will; if for aarch64 LTO will depend on RCpc, but RCpc is an ARMv8.3 extension, what are the implications for LTO on pre-ARMv8.3 aarch64 processors?

So I'd recommend to Sami to simply make the Kconfig also depend on clang's integrated assembler (not just llvm-nm and llvm-ar).

Quoted 3 lines · Nick Desaulniers

So I'd recommend to Sami to simply make the Kconfig also depend on clang's integrated assembler (not just llvm-nm and llvm-ar).

Sure, sounds good to me. What's the preferred way to test for this in Kconfig?

It looks like actually trying to test if we have an LLVM assembler (e.g. using $(as-instr,.section ".linker-options","e",@llvm_linker_options)) doesn't work as Kconfig doesn't pass -no-integrated-as to clang here. I could do something simple like $(success,echo $(LLVM) $(LLVM_IAS) | grep -q "1 1").

Thoughts?

Sami

Quoted 5 lines · Sami Tolvanen

Quoted 3 lines · Nick Desaulniers

So I'd recommend to Sami to simply make the Kconfig also depend on clang's integrated assembler (not just llvm-nm and llvm-ar).

Quoted 6 lines

Sure, sounds good to me. What's the preferred way to test for this in Kconfig?

It looks like actually trying to test if we have an LLVM assembler (e.g. using $(as-instr,.section ".linker-options","e",@llvm_linker_options)) doesn't work as Kconfig doesn't pass -no-integrated-as to clang here.

Quoted 5 lines

I could do something
simple like $(success,echo $(LLVM) $(LLVM_IAS) | grep -q "1 1").

Thoughts?

Quoted 1 line

Sami

I think

    depends on $(success,test $(LLVM_IAS) -eq 1)

should work, at least according to my brief test.

Sure, looks good to me. However, I think we should also test for LLVM=1 to avoid possible further issues with mismatched toolchains instead of only checking for llvm-nm and llvm-ar.

This patch series adds support for building the kernel with Clang's Link Time Optimization (LTO). In addition to performance, the primary motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to be used in the kernel. Google has shipped millions of Pixel devices running three major kernel versions with LTO+CFI since 2018.

Most of the patches are build system changes for handling LLVM bitcode, which Clang produces with LTO instead of ELF object files, postponing ELF processing until a later stage, and ensuring initcall ordering.

Note that arm64 support depends on Will's memory ordering patches [1]. I will post x86_64 patches separately after we have fixed the remaining objtool warnings [2][3].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/lto
[2] https://lore.kernel.org/lkml/20201120040424.a3wctajzft4ufoiw@treble/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool-vmlinux

You can also pull this series from

https://github.com/samitolvanen/linux.git lto-v8

Quoted 2 lines

Quoted 2 lines

defined in net/qrtr/qrtr.lto.o
defined in net/qrtr/qrtr.o

Quoted 2 lines

Quoted 2 lines

defined in crypto/842.lto.o
defined in crypto/842.o

Quoted 2 lines

Quoted 2 lines

defined in net/netfilter/nfnetlink_log.lto.o
defined in net/netfilter/nfnetlink_log.o

Quoted 2 lines

Quoted 2 lines

defined in crypto/ecc.lto.o
defined in crypto/ecc.o

Quoted 2 lines

Quoted 2 lines

defined in drivers/clk/clk-plldig.lto.o
defined in drivers/clk/clk-plldig.o

On Tue, Dec 1, 2020 at 10:37 PM 'Sami Tolvanen' via Clang Built Linux <[email protected]> wrote:

- many builds complain about thousands of duplicate symbols in the kernel, e.g. ld.lld: error: duplicate symbol: qrtr_endpoint_post

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

defined in net/qrtr/qrtr.lto.o
defined in net/qrtr/qrtr.o

ld.lld: error: duplicate symbol: init_module

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

defined in crypto/842.lto.o
defined in crypto/842.o

ld.lld: error: duplicate symbol: init_module

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

defined in net/netfilter/nfnetlink_log.lto.o
defined in net/netfilter/nfnetlink_log.o

ld.lld: error: duplicate symbol: vli_from_be64

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

defined in crypto/ecc.lto.o
defined in crypto/ecc.o

ld.lld: error: duplicate symbol: __mod_of__plldig_clk_id_device_table

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

defined in drivers/clk/clk-plldig.lto.o
defined in drivers/clk/clk-plldig.o

Quoted 9 lines · Arnd Bergmann

On Tue, Dec 1, 2020 at 10:37 PM 'Sami Tolvanen' via Clang Built Linux <[email protected]> wrote:

- many builds complain about thousands of duplicate symbols in the kernel, e.g. ld.lld: error: duplicate symbol: qrtr_endpoint_post

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

defined in net/qrtr/qrtr.lto.o
defined in net/qrtr/qrtr.o

ld.lld: error: duplicate symbol: init_module

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

defined in crypto/842.lto.o
defined in crypto/842.o

Quoted 9 lines

ld.lld: error: duplicate symbol: init_module

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

defined in net/netfilter/nfnetlink_log.lto.o
defined in net/netfilter/nfnetlink_log.o

ld.lld: error: duplicate symbol: vli_from_be64

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

defined in crypto/ecc.lto.o
defined in crypto/ecc.o

ld.lld: error: duplicate symbol: __mod_of__plldig_clk_id_device_table

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

defined in drivers/clk/clk-plldig.lto.o
defined in drivers/clk/clk-plldig.o

A small update here: I see this behavior with every single module build, including 'tinyconfig' with one module enabled, and 'defconfig'.

Quoted 3 lines

A small update here: I see this behavior with every single module build, including 'tinyconfig' with one module enabled, and 'defconfig'.

The .o file here is a thin archive of the bitcode files for the module. We compile .lto.o from that before modpost, because we need an ELF binary to process, and then reuse the .lto.o file when linking the final module.

At no point should we link the .o file again, especially not with .lto.o, because that would clearly cause every symbol to be duplicated, so I'm not sure what goes wrong here. Here's the relevant part of scripts/Makefile.modfinal:

ifdef CONFIG_LTO_CLANG
# With CONFIG_LTO_CLANG, reuse the object file we compiled for modpost to

# avoid a second slow LTO link
prelink-ext := .lto
...
$(modules): %.ko: %$(prelink-ext).o %.mod.o scripts/module.lds FORCE
        +$(call if_changed,ld_ko_o)

Quoted 20 lines · Sami Tolvanen' via Clang Built Linux

This patch series adds support for building the kernel with Clang's Link Time Optimization (LTO). In addition to performance, the primary motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to be used in the kernel. Google has shipped millions of Pixel devices running three major kernel versions with LTO+CFI since 2018.

Most of the patches are build system changes for handling LLVM bitcode, which Clang produces with LTO instead of ELF object files, postponing ELF processing until a later stage, and ensuring initcall ordering.

Note that arm64 support depends on Will's memory ordering patches [1]. I will post x86_64 patches separately after we have fixed the remaining objtool warnings [2][3].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/lto
[2] https://lore.kernel.org/lkml/20201120040424.a3wctajzft4ufoiw@treble/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool-vmlinux

Quoted 3 lines

You can also pull this series from

https://github.com/samitolvanen/linux.git lto-v8

I've tried pull this into my randconfig test tree to give it a spin.

So far I have
not managed to get a working build out of it, the main problem so far being that it is really slow to build because the link stage only uses one CPU. These are the other issues I've seen so far:

- one build seems to take even longer to link. It's currently at 35GB RAM usage and 40 minutes into the final link, but I'm worried it might
not complete
before it runs out of memory. I only have 128GB installed, and google-chrome uses another 30GB of that, and I'm also doing some other builds in parallel. Is there a minimum recommended amount of memory for doing LTO builds?

- One build failed with
ld.lld -EL -maarch64elf -mllvm -import-instr-limit=5 -r -o vmlinux.o
-T .tmp_initcalls.lds --whole-archive arch/arm64/kernel/head.o init/built-in.a usr/built-in.a arch/arm64/built-in.a kernel/built-in.a

certs/built-in.a mm/built-in.a fs/built-in.a ipc/built-in.a security/built-in.a crypto/built-in.a block/built-in.a arch/arm64/lib/built-in.a lib/built-in.a drivers/built-in.a sound/built-in.a net/built-in.a virt/built-in.a --no-whole-archive --start-group arch/arm64/lib/lib.a lib/lib.a ./drivers/firmware/efi/libstub/lib.a --end-group
"ld.lld: error: arch/arm64/kernel/head.o: invalid symbol index" after about 30 minutes

- CONFIG_CPU_BIG_ENDIAN doesn't seem to work with lld, and LTO doesn't work with ld.bfd.
I've added a CPU_LITTLE_ENDIAN dependency to ARCH_SUPPORTS_LTO_CLANG{,THIN}

Not sure if these are all known issues. If there is one you'd like me try take a closer look at for finding which config options break it, I can try

Quoted 23 lines · Arnd Bergmann

Quoted 20 lines · Sami Tolvanen' via Clang Built Linux

This patch series adds support for building the kernel with Clang's Link Time Optimization (LTO). In addition to performance, the primary motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to be used in the kernel. Google has shipped millions of Pixel devices running three major kernel versions with LTO+CFI since 2018.

Most of the patches are build system changes for handling LLVM bitcode, which Clang produces with LTO instead of ELF object files, postponing ELF processing until a later stage, and ensuring initcall ordering.

Note that arm64 support depends on Will's memory ordering patches [1]. I will post x86_64 patches separately after we have fixed the remaining objtool warnings [2][3].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/lto
[2] https://lore.kernel.org/lkml/20201120040424.a3wctajzft4ufoiw@treble/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool-vmlinux

Quoted 5 lines

Quoted 3 lines

You can also pull this series from

https://github.com/samitolvanen/linux.git lto-v8

I've tried pull this into my randconfig test tree to give it a spin.

Great, thank you for testing this!

Quoted 4 lines

So far I have
not managed to get a working build out of it, the main problem so far being that it is really slow to build because the link stage only uses one CPU. These are the other issues I've seen so far:

You may want to limit your testing only to ThinLTO at first, because full LTO is going to be extremely slow with larger configs, especially when building arm64 kernels.

Quoted 6 lines

- one build seems to take even longer to link. It's currently at 35GB RAM usage and 40 minutes into the final link, but I'm worried it might
not complete
before it runs out of memory. I only have 128GB installed, and google-chrome uses another 30GB of that, and I'm also doing some other builds in parallel. Is there a minimum recommended amount of memory for doing LTO builds?

When building arm64 defconfig, the maximum memory usage I measured with ThinLTO was 3.5 GB, and with full LTO 20.3 GB. I haven't measured larger configurations, but I believe LLD can easily consume 3-4x that much with full LTO allyesconfig.

Quoted 4 lines

- One build failed with
ld.lld -EL -maarch64elf -mllvm -import-instr-limit=5 -r -o vmlinux.o
-T .tmp_initcalls.lds --whole-archive arch/arm64/kernel/head.o init/built-in.a usr/built-in.a arch/arm64/built-in.a kernel/built-in.a

Quoted 8 lines

certs/built-in.a mm/built-in.a fs/built-in.a ipc/built-in.a security/built-in.a crypto/built-in.a block/built-in.a arch/arm64/lib/built-in.a lib/built-in.a drivers/built-in.a sound/built-in.a net/built-in.a virt/built-in.a --no-whole-archive --start-group arch/arm64/lib/lib.a lib/lib.a ./drivers/firmware/efi/libstub/lib.a --end-group
"ld.lld: error: arch/arm64/kernel/head.o: invalid symbol index" after about 30 minutes

That's interesting. Did you use LLVM_IAS=1?

[...]

Quoted 2 lines

Not sure if these are all known issues. If there is one you'd like me try take a closer look at for finding which config options break it, I can try

No, none of these are known issues. I would be happy to take a closer look if you can share configs that reproduce these.

Attaching the config for "ld.lld: error: Never resolved function from
blockaddress (Producer: 'LLVM12.0.0' Reader: 'LLVM 12.0.0')"

Quoted 3 lines · Arnd Bergmann

Attaching the config for "ld.lld: error: Never resolved function from
blockaddress (Producer: 'LLVM12.0.0' Reader: 'LLVM 12.0.0')"

And here is a new one: "ld.lld: error: assignment to symbol init_pg_end does not converge"

Arnd

Quoted 6 lines · Arnd Bergmann

Quoted 3 lines · Arnd Bergmann

Attaching the config for "ld.lld: error: Never resolved function from
blockaddress (Producer: 'LLVM12.0.0' Reader: 'LLVM 12.0.0')"

Quoted 2 lines

And here is a new one: "ld.lld: error: assignment to symbol init_pg_end does not converge"

This is interesting. I changed the symbol assignment to a separate loop in https://reviews.llvm.org/D66279
Does raising the limit help? Sometimes the kernel linker script can be rewritten to be more friendly to the linker...

Quoted 3 lines · Arnd Bergmann

Attaching the config for "ld.lld: error: Never resolved function from
blockaddress (Producer: 'LLVM12.0.0' Reader: 'LLVM 12.0.0')"

And here is a new one: "ld.lld: error: assignment to symbol init_pg_end does not converge"

Quoted 3 lines · Arnd Bergmann

Attaching the config for "ld.lld: error: Never resolved function from
blockaddress (Producer: 'LLVM12.0.0' Reader: 'LLVM 12.0.0')"

And here is a new one: "ld.lld: error: assignment to symbol init_pg_end does not converge"

Quoted 7 lines · Arnd Bergmann

Quoted 3 lines · Arnd Bergmann

Attaching the config for "ld.lld: error: Never resolved function from
blockaddress (Producer: 'LLVM12.0.0' Reader: 'LLVM 12.0.0')"

And here is a new one: "ld.lld: error: assignment to symbol init_pg_end does not converge"

Thanks for these. I can reproduce the "Never resolved function from blockaddress" issue with full LTO, but I couldn't reproduce this one with ToT Clang, and the config doesn't have LTO enabled:

$ grep LTO 0x2824F594_defconfig
CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y

Is this the correct config file?

Quoted 10 lines · Sami Tolvanen' via Clang Built Linux

Quoted 7 lines · Arnd Bergmann

- one build seems to take even longer to link. It's currently at 35GB RAM usage and 40 minutes into the final link, but I'm worried it might
not complete
before it runs out of memory. I only have 128GB installed, and google-chrome uses another 30GB of that, and I'm also doing some other builds in parallel. Is there a minimum recommended amount of memory for doing LTO builds?

Quoted 4 lines

When building arm64 defconfig, the maximum memory usage I measured with ThinLTO was 3.5 GB, and with full LTO 20.3 GB. I haven't measured larger configurations, but I believe LLD can easily consume 3-4x that much with full LTO allyesconfig.

Ok, that's not too bad then. Is there actually a reason to still support full-lto
in your series? As I understand it, full LTO was the initial approach and used to work better, but thin LTO is actually what we want to use in the long run. Perhaps dropping the full LTO option from your series now that thin LTO works well enough and uses less resources would help avoid some of the problems.

Quoted 18 lines · Arnd Bergmann

Quoted 10 lines · Sami Tolvanen' via Clang Built Linux

Quoted 7 lines · Arnd Bergmann

- one build seems to take even longer to link. It's currently at 35GB RAM usage and 40 minutes into the final link, but I'm worried it might
not complete
before it runs out of memory. I only have 128GB installed, and google-chrome uses another 30GB of that, and I'm also doing some other builds in parallel. Is there a minimum recommended amount of memory for doing LTO builds?

Quoted 4 lines

When building arm64 defconfig, the maximum memory usage I measured with ThinLTO was 3.5 GB, and with full LTO 20.3 GB. I haven't measured larger configurations, but I believe LLD can easily consume 3-4x that much with full LTO allyesconfig.

Quoted 7 lines

Ok, that's not too bad then. Is there actually a reason to still support full-lto
in your series? As I understand it, full LTO was the initial approach and used to work better, but thin LTO is actually what we want to use in the long run. Perhaps dropping the full LTO option from your series now that thin LTO works well enough and uses less resources would help avoid some of the problems.

While all developers agree that ThinLTO is a much more palatable experience than full LTO; our product teams prefer the excessive build time and memory high water mark (at build time) costs in exchange for slightly better performance than ThinLTO in <benchmarks that I've been told are important>. Keeping support for full LTO in tree would help our product teams reduce the amount of out of tree code they have. As long as <benchmarks that I've been told are important> help sell/differentiate phones, I suspect our product teams will continue to ship full LTO in production.

Quoted 28 lines · Nick Desaulniers' via Clang Built Linux

Quoted 18 lines · Arnd Bergmann

Quoted 10 lines · Sami Tolvanen' via Clang Built Linux

Quoted 7 lines · Arnd Bergmann

- one build seems to take even longer to link. It's currently at 35GB RAM usage and 40 minutes into the final link, but I'm worried it might
not complete
before it runs out of memory. I only have 128GB installed, and google-chrome uses another 30GB of that, and I'm also doing some other builds in parallel. Is there a minimum recommended amount of memory for doing LTO builds?

Quoted 4 lines

When building arm64 defconfig, the maximum memory usage I measured with ThinLTO was 3.5 GB, and with full LTO 20.3 GB. I haven't measured larger configurations, but I believe LLD can easily consume 3-4x that much with full LTO allyesconfig.

Quoted 7 lines

Ok, that's not too bad then. Is there actually a reason to still support full-lto
in your series? As I understand it, full LTO was the initial approach and used to work better, but thin LTO is actually what we want to use in the long run. Perhaps dropping the full LTO option from your series now that thin LTO works well enough and uses less resources would help avoid some of the problems.

Quoted 9 lines

While all developers agree that ThinLTO is a much more palatable experience than full LTO; our product teams prefer the excessive build time and memory high water mark (at build time) costs in exchange for slightly better performance than ThinLTO in <benchmarks that I've been told are important>. Keeping support for full LTO in tree would help our product teams reduce the amount of out of tree code they have. As long as <benchmarks that I've been told are important> help sell/differentiate phones, I suspect our product teams will continue to ship full LTO in production.

Ok, fair enough. How about marking FULL_LTO as 'depends on !COMPILE_TEST' then? I'll do that locally for my randconfig tests, but it would help the other build bots that also force-enable COMPILE_TEST.

Quoted 23 lines · Arnd Bergmann

Quoted 20 lines · Sami Tolvanen' via Clang Built Linux

This patch series adds support for building the kernel with Clang's Link Time Optimization (LTO). In addition to performance, the primary motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to be used in the kernel. Google has shipped millions of Pixel devices running three major kernel versions with LTO+CFI since 2018.

Most of the patches are build system changes for handling LLVM bitcode, which Clang produces with LTO instead of ELF object files, postponing ELF processing until a later stage, and ensuring initcall ordering.

Note that arm64 support depends on Will's memory ordering patches [1]. I will post x86_64 patches separately after we have fixed the remaining objtool warnings [2][3].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/lto
[2] https://lore.kernel.org/lkml/20201120040424.a3wctajzft4ufoiw@treble/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool-vmlinux

Quoted 5 lines

Quoted 3 lines

You can also pull this series from

https://github.com/samitolvanen/linux.git lto-v8

I've tried pull this into my randconfig test tree to give it a spin.

Great, thank you for testing this!

Quoted 4 lines

So far I have
not managed to get a working build out of it, the main problem so far being that it is really slow to build because the link stage only uses one CPU. These are the other issues I've seen so far:

You may want to limit your testing only to ThinLTO at first, because full LTO is going to be extremely slow with larger configs, especially when building arm64 kernels.

Quoted 6 lines

- one build seems to take even longer to link. It's currently at 35GB RAM usage and 40 minutes into the final link, but I'm worried it might
not complete
before it runs out of memory. I only have 128GB installed, and google-chrome uses another 30GB of that, and I'm also doing some other builds in parallel. Is there a minimum recommended amount of memory for doing LTO builds?

When building arm64 defconfig, the maximum memory usage I measured with ThinLTO was 3.5 GB, and with full LTO 20.3 GB. I haven't measured larger configurations, but I believe LLD can easily consume 3-4x that much with full LTO allyesconfig.

Quoted 4 lines

- One build failed with
ld.lld -EL -maarch64elf -mllvm -import-instr-limit=5 -r -o vmlinux.o
-T .tmp_initcalls.lds --whole-archive arch/arm64/kernel/head.o init/built-in.a usr/built-in.a arch/arm64/built-in.a kernel/built-in.a

Quoted 8 lines

certs/built-in.a mm/built-in.a fs/built-in.a ipc/built-in.a security/built-in.a crypto/built-in.a block/built-in.a arch/arm64/lib/built-in.a lib/built-in.a drivers/built-in.a sound/built-in.a net/built-in.a virt/built-in.a --no-whole-archive --start-group arch/arm64/lib/lib.a lib/lib.a ./drivers/firmware/efi/libstub/lib.a --end-group
"ld.lld: error: arch/arm64/kernel/head.o: invalid symbol index" after about 30 minutes

That's interesting. Did you use LLVM_IAS=1?

Quoted 4 lines

- CONFIG_CPU_BIG_ENDIAN doesn't seem to work with lld, and LTO doesn't work with ld.bfd.
I've added a CPU_LITTLE_ENDIAN dependency to ARCH_SUPPORTS_LTO_CLANG{,THIN}

Ah, good point. I'll fix this in v9.

[...]

Quoted 2 lines

Not sure if these are all known issues. If there is one you'd like me try take a closer look at for finding which config options break it, I can try

No, none of these are known issues. I would be happy to take a closer look if you can share configs that reproduce these.

Sami

Signature · 3 lines

You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/CABCJKueCHo2RYfx_A21m%2B%3Dd1gQLR9QsOOxCsHFeicCqyHkb-Kg%40mail.gmail.com.

Quoted 5 lines · Sami Tolvanen' via Clang Built Linux

Quoted 4 lines · Arnd Bergmann

So far I have
not managed to get a working build out of it, the main problem so far being that it is really slow to build because the link stage only uses one CPU. These are the other issues I've seen so far:

ld.lld ThinLTO uses the number of (physical cores enabled by affinity) by default.

Quoted 6 lines

Quoted 4 lines

- CONFIG_CPU_BIG_ENDIAN doesn't seem to work with lld, and LTO doesn't work with ld.bfd.
I've added a CPU_LITTLE_ENDIAN dependency to ARCH_SUPPORTS_LTO_CLANG{,THIN}

Ah, good point. I'll fix this in v9.

Full/Thin LTO should work with GNU ld and gold with LLVMgold.so built from llvm-project (https://llvm.org/docs/GoldPlugin.html ). You'll need to make sure that LLVMgold.so is newer than clang. (Newer clang may introduce bitcode attributes which are unrecognizable by older LLVMgold.so/ld.lld)

- one build seems to have dropped all symbols the string operations from vmlinux,
so while the link goes through, modules cannot be loaded:
ERROR: modpost: "memmove" [drivers/media/rc/rc-core.ko] undefined!
ERROR: modpost: "memcpy" [net/wireless/cfg80211.ko] undefined!
ERROR: modpost: "memcpy" [net/8021q/8021q.ko] undefined!
ERROR: modpost: "memset" [net/8021q/8021q.ko] undefined!
ERROR: modpost: "memcpy" [net/unix/unix.ko] undefined!
ERROR: modpost: "memset" [net/sched/cls_u32.ko] undefined!
ERROR: modpost: "memcpy" [net/sched/cls_u32.ko] undefined!
ERROR: modpost: "memset" [net/sched/sch_skbprio.ko] undefined!
ERROR: modpost: "memcpy" [net/802/garp.ko] undefined!
I first thought this was related to a clang-12 bug I saw the other day, but this also happens with clang-11

Quoted 15 lines · Arnd Bergmann

- one build seems to have dropped all symbols the string operations from vmlinux,
so while the link goes through, modules cannot be loaded:
ERROR: modpost: "memmove" [drivers/media/rc/rc-core.ko] undefined!
ERROR: modpost: "memcpy" [net/wireless/cfg80211.ko] undefined!
ERROR: modpost: "memcpy" [net/8021q/8021q.ko] undefined!
ERROR: modpost: "memset" [net/8021q/8021q.ko] undefined!
ERROR: modpost: "memcpy" [net/unix/unix.ko] undefined!
ERROR: modpost: "memset" [net/sched/cls_u32.ko] undefined!
ERROR: modpost: "memcpy" [net/sched/cls_u32.ko] undefined!
ERROR: modpost: "memset" [net/sched/sch_skbprio.ko] undefined!
ERROR: modpost: "memcpy" [net/802/garp.ko] undefined!
I first thought this was related to a clang-12 bug I saw the other day, but this also happens with clang-11

It seems to happen because of CONFIG_TRIM_UNUSED_KSYMS, which is a shame, since I think that is an option we'd always want to have enabled with LTO, to allow more dead code to be eliminated.

Quoted 7 lines · Arnd Bergmann

On Tue, Dec 8, 2020 at 1:15 PM Arnd Bergmann <[email protected]> wrote:

It seems to happen because of CONFIG_TRIM_UNUSED_KSYMS, which is a shame, since I think that is an option we'd always want to have enabled with LTO, to allow more dead code to be eliminated.

Ah yes, this is a known issue. We use TRIM_UNUSED_KSYMS with LTO in Android's Generic Kernel Image and the problem is that bitcode doesn't yet contain calls to these functions, so autoksyms won't see them. The solution is to use a symbol whitelist with LTO to prevent these from being trimmed. I suspect we would need a default whitelist for LTO builds.