On Wed, Sep 30, 2020 at 2:58 PM Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote: > > On Tue, Sep 29, 2020 at 2:46 PM Sami Tolvanen <samitolvanen@xxxxxxxxxx> wrote: > > > > This patch series adds support for building x86_64 and arm64 kernels > > 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. > > Sami, thanks for continuing to drive the series. I encourage you to > keep resending with fixes accumulated or dropped on a weekly cadence. > > The series worked well for me on arm64, but for x86_64 on mainline I > saw a stream of new objtool warnings: [...] Objtool normally won't print out these warnings when run on vmlinux.o, but we can't pass --vmlinux to objtool as that also implies noinstr validation right now. I think we'd have to split that from --vmlinux to avoid these. I can include a patch to add a --noinstr flag in v5. Peter, any thoughts about this? > I think those should be resolved before I provide any kind of tested > by tag. My other piece of feedback was that I like the default > ThinLTO, but I think the help text in the Kconfig which is visible > during menuconfig could be improved by informing the user the > tradeoffs. For example, if CONFIG_THINLTO is disabled, it should be > noted that full LTO will be used instead. Also, that full LTO may > produce slightly better optimized binaries than ThinLTO, at the cost > of not utilizing multiple cores when linking and thus significantly > slower to link. > > Maybe explaining that setting it to "n" implies a full LTO build, > which will be much slower to link but possibly slightly faster would > be good? It's not visible unless LTO_CLANG and ARCH_SUPPORTS_THINLTO > is enabled, so I don't think you need to explain that THINLTO without > those is *not* full LTO. I'll leave the precise wording to you. WDYT? Sure, sounds good. I'll update the help text in the next version. > Also, when I look at your treewide DISABLE_LTO patch, I think "does > that need to be a part of this series, or is it a cleanup that can > stand on its own?" I think it may be the latter? Maybe it would help > shed one more patch than to have to carry it to just send it? Or did > I miss something as to why it should remain a part of this series? I suppose it could be stand-alone, but as these patches are also disabling LTO by filtering out flags in some of the same files, removing the unused DISABLE_LTO flags first would reduce confusion. But I'm fine with sending it separately too if that's preferred. Sami
