[PATCH v4 09/14] kbuild: do not create *.prelink.o for Clang LTO or IBT
Sami Tolvanen
samitolvanen at google.com
Tue May 10 09:13:11 AEST 2022
On Sun, May 8, 2022 at 12:10 PM Masahiro Yamada <masahiroy at kernel.org> 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 at kernel.org>
> Reviewed-by: Nicolas Schier <nicolas at fjasle.eu>
> Tested-by: Nathan Chancellor <nathan at kernel.org>
Looks good, thanks for cleaning this up!
Reviewed-by: Sami Tolvanen <samitolvanen at google.com>
Sami
More information about the Linuxppc-dev
mailing list