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]
Message-ID: <alpine.LFD.2.20.1707090946090.1959@knanqh.ubzr>
Date:   Sun, 9 Jul 2017 09:59:44 -0400 (EDT)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
cc:     Ingo Molnar <mingo@...nel.org>,
        Nicholas Piggin <npiggin@...il.com>,
        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, 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?
> >
> > 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. 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.


Nicolas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ