Re: [PATCH 0/4] kbuild: build speed improvment of CONFIG_TRIM_UNUSED_KSYMS
From: Nicolas Pitre
Date: Thu Feb 25 2021 - 14:28:36 EST
On 2021年2月26日, Masahiro Yamada wrote:
>
On Fri, Feb 26, 2021 at 2:20 AM Nicolas Pitre <nico@xxxxxxxxxxx> wrote:
>
>
>
> On 2021年2月26日, Masahiro Yamada wrote:
>
>
>
> >
>
> > Now CONFIG_TRIM_UNUSED_KSYMS is revived, but Linus is still unhappy
>
> > about the build speed.
>
> >
>
> > I re-implemented this feature, and the build time cost is now
>
> > almost unnoticeable level.
>
> >
>
> > I hope this makes Linus happy.
>
>
>
> :-)
>
>
>
> I'm surprised to see that Linus is using this feature. When disabled
>
> (the default) this should have had no impact on the build time.
>
>
Linus is not using this feature, but does build tests.
>
After pulling the module subsystem pull request in this merge window,
>
CONFIG_TRIM_UNUSED_KSYMS was enabled by allmodconfig.
If CONFIG_TRIM_UNUSED_KSYMS is enabled then build time willincrease.
That comes with the feature.
>
> This feature provides a nice security advantage by significantly
>
> reducing the kernel input surface. And people are using that also to
>
> better what third party vendor can and cannot do with a distro kernel,
>
> etc. But that's not the reason why I implemented this feature in the
>
> first place.
>
>
>
> My primary goal was to efficiently reduce the kernel binary size using
>
> LTO even with kernel modules enabled.
>
>
>
Clang LTO landed in this MW.
>
>
Do you think it will reduce the kernel binary size?
>
No, opposite.
LTO ought to reduce binary size. It is rather broken otherwise.
Having a global view before optimizing allows for the compiler to do
project wide constant propagation and dead code elimination.
>
CONFIG_LTO_CLANG cannot trim any code even if it
>
is obviously unused.
>
Hence, it never reduces the kernel binary size.
>
Rather, it produces a bigger kernel.
Then what's the point?
>
The reason is Clang LTO was implemented against
>
relocatable ELF (vmlinux.o) .
That's not true LTO then.
>
I pointed out this flaw in the review process, but
>
it was dismissed.
>
>
This is the main reason why I did not give any Ack
>
(but it was merged via Kees Cook's tree).
>
So, the help text of this option should be revised:
>
>
This option allows for unused exported symbols to be dropped from
>
the build. In turn, this provides the compiler more opportunities
>
(especially when using LTO) for optimizing the code and reducing
>
binary size. This might have some security advantages as well.
>
>
Clang LTO is opposite to your expectation.
Then Clang LTO is a misnomer. That is the option to revise not this one.
>
> Each EXPORT_SYMBOL() created a
>
> symbol dependency that prevented LTO from optimizing out the related
>
> code even though a tiny fraction of those exported symbols were needed.
>
>
>
> The idea behind the recursion was to catch those cases where disabling
>
> an exported symbol within a module would optimize out references to more
>
> exported symbols that, in turn, could be disabled and possibly trigger
>
> yet more code elimination. There is no way that can be achieved without
>
> extra compiler passes in a recursive manner.
>
>
I do not understand.
>
>
Modules are relocatable ELF.
>
Clang LTO cannot eliminate any code.
>
GCC LTO does not work with relocatable ELF
>
in the first place.
I don't think I follow you here. What relocatable ELF has to do with LTO?
I've successfully used gcc LTO on the kernel quite a while ago.
For a reference about binary size reduction with LTO and
CONFIG_TRIM_UNUSED_KSYMS please read this article:
https://lwn.net/Articles/746780/
Nicolas