Re: [PATCH v4 09/14] kbuild: do not create *.prelink.o for Clang LTO or IBT
From: Sami Tolvanen <samitolvanen@google.com>
Date: 2022-05-09 23:13:58
Also in:
linux-kbuild, linux-modules, linux-s390, lkml
On Sun, May 8, 2022 at 12:10 PM Masahiro Yamada [off-list ref] wrote:
When CONFIG_LTO_CLANG=y, additional intermediate *.prelink.o is created
for each module. Also, objtool is postponed until LLVM bitcode is
converted to ELF.
CONFIG_X86_KERNEL_IBT works in a similar way to postpone objtool until
objects are merged together.
This commit stops generating *.prelink.o, so the build flow will look
the same with/without LTO.
The following figures show how the LTO build currently works, and
how this commit is changing it.
Current build flow
==================
[1] single-object module
$(LD)
$(CC) +objtool $(LD)
foo.c --------------------> foo.o -----> foo.prelink.o -----> foo.ko
(LLVM bitcode) (ELF) |
|
foo.mod.o --/
[2] multi-object module
$(LD)
$(CC) $(AR) +objtool $(LD)
foo1.c -----> foo1.o -----> foo.o -----> foo.prelink.o -----> foo.ko
| (archive) (ELF) |
foo2.c -----> foo2.o --/ |
(LLVM bitcode) foo.mod.o --/
One confusion is foo.o in multi-object module is an archive despite of
its suffix.
New build flow
==============
[1] single-object module
Since there is only one object, we do not need to have the LLVM
bitcode stage. Use $(CC)+$(LD) to generate an ELF object in one
build rule. When LTO is disabled, $(LD) is unneeded because $(CC)
produces an ELF object.
$(CC)+$(LD)+objtool $(LD)
foo.c ------------------------> foo.o -------> foo.ko
(ELF) |
|
foo.mod.o --/
[2] multi-object module
Previously, $(AR) was used to combine LLVM bitcode into an archive,
but there was no technical reason to do so.
This commit just uses $(LD) to combine and convert them into a single
ELF object.
$(LD)
$(CC) +objtool $(LD)
foo1.c -------> foo1.o -------> foo.o -------> foo.ko
| (ELF) |
foo2.c -------> foo2.o ---/ |
(LLVM bitcode) foo.mod.o --/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <redacted>
Tested-by: Nathan Chancellor <nathan@kernel.org>Looks good, thanks for cleaning this up! Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Sami