linux-kernel - Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 Jul 2017 12:13:29 +1000
From:   Nicholas Piggin <npiggin@...il.com>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Ingo Molnar <mingo@...nel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        X86 ML <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Paul Burton <paul.burton@...tec.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)

On Sun, 9 Jul 2017 09:59:44 -0400 (EDT)
Nicolas Pitre <nicolas.pitre@...aro.org> wrote:

> On Sun, 9 Jul 2017, Masahiro Yamada wrote:
> 
> > Hi.
> > 
> > 2017-07-09 18:05 GMT+09:00 Ingo Molnar <mingo@...nel.org>:  
> > >
> > > * Nicholas Piggin <npiggin@...il.com> wrote:
> > >  
> > >> FYI, easiest way to check if you forgot to KEEP a linker table is
> > >> to look at `readelf -S vmlinux` differences, and to see what is
> > >> being trimmed, look at nm differences or use --print-gc-sections
> > >> LD option to see what symbols you're trimming. Linker tables,
> > >> boot entry, and exception entry tends to require anchoring.  
> > >
> > > Could you please add a debug build target to display all discarded
> > > symbols/sections? Something like:
> > >
> > >         make lto-check
> > >
> > > ... or so?

Some kind of option like this could be a good idea. It could apply
to any kind of link-time optimization we do. I'll think about it.

> > >
> > > Thanks,
> > >
> > >         Ingo  
> > 
> > 
> > Actually, LTO activity existed some years ago
> > (but not pulled in).
> > 
> > http://www.spinics.net/lists/linux-kbuild/msg09242.html
> > 
> > 
> > IIUC, this patch enables "dead code elimination",
> > (or "garbage collection"?),
> > but I think it is different from what is called LTO.  
> 
> Yes, it is different.  With gc-sections the linker simply drops code 
> sections that have no references to them.

Yes, I shouldn't have confused the terms. gc-sections is a trivial
form of LTO, but not "LTO".

> This is therefore fast and low 
> complexity.  LTO postpones the compiler's code optimization passes at 
> the point where everything is linked together and can do things like 
> constant propagation across multiple files, etc. LTO is therefore more 
> efficient at removing unused code but compilation time is much longer 
> due to the added complexity and inherent difficulty to parallelize the 
> operation across multiple CPUS.
> 
> I think we should aim for gc-sections to be used by default and have LTO 
> as a possible option only.

I agree after it starts getting implemented and debugged by small
system users, we could make it default in the interest of sharing
testing and reducing combinations.

Thanks,
Nick