[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151101195658.GL8645@brightrain.aerifal.cx>
Date: Sun, 1 Nov 2015 14:56:58 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] configure: add gcc flags for better link-time
optimization
On Fri, Oct 23, 2015 at 02:30:26PM +0200, Denys Vlasenko wrote:
> +#
> +# Put every function and data object into its own section:
> +# .text.funcname, .data.var, .rodata.const_struct, .bss.zerovar
> +#
> +# Previous optimization isn't working too well by itself
> +# because data objects aren't living in separate sections,
> +# they are all grouped in one .data and one .bss section per *.o file.
> +# With -ffunction/data-sections, section sorting eliminates more padding.
> +#
> +# Object files in static *.a files will also have their functions
> +# and data objects each in its own section.
> +#
> +# This enables programs statically linked with -Wl,--gc-sections
> +# to perform "section garbage collection": drop unused code and data
> +# not on per-*.o-file basis, but on per-function and per-object basis.
> +# This is a big thing: --gc-sections sometimes eliminates several percent
> +# of unreachable code and data in final executable.
> +#
> +tryflag CFLAGS_AUTO -ffunction-sections
> +tryflag CFLAGS_AUTO -fdata-sections
> +
> +#
This is not just an optimization but going to save us from a horrible
class of compiler/assembler bugs that threatened to force dropping
support for all non-bleeding-edge toolchains:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609
https://sourceware.org/bugzilla/show_bug.cgi?id=18561
By putting functions/objects in their own sections, the illegal but
widespread assembler 'optimization' of resolving differences between
symbols to a constant when one or both of the symbols has a weak
definition is suppressed, simply because differences of this form are
never constants when they cross sections.
As such I want to go ahead and apply this regardless of optimization
issues, but I think we should update the comments and commit message
to reflect that this is also working around serious toolchain issues.
I hope to get to it soon now; working on some other things at the
moment.
BTW thanks a lot for raising the idea of using these options. If it
hadn't been for your pending patch I probably would never have thought
of this as a solution to the toolchain problems above.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
