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]

Message-ID: <87a849aaa3.fsf@firstfloor.org>
Date:   Wed, 12 Jul 2017 09:29:40 -0700
From:   Andi Kleen <andi@...stfloor.org>
To:     npiggin@...il.com
cc:     linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)

Nicholas Piggin <npiggin@...il.com> writes:
>> 
>> 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.

>From what i understand the main drawback in the past was
is that various linker versions become very slow with thousands of
sections.

So it may cost you built time. For a special small build it's probably
ok, but you wouldn't want to make it default.

Also usually it's only useful without modules because if you
use modules EXPORT_SYMBOL pulls in a lot of unused functions.

BTW I'm still maintaining a "real LTO" patchkit here, which
has some users (mainly for binary size), but also gives some
performance. Should probably resubmit it again. The main
issue was that the old single link patch is still not forward
ported.

https://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git/log/?h=lto-411-2

-Andi