This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Proposed patch] Huge performance regression in ld -r since binutils >= 2.21
- From: Rich Felker <dalias at libc dot org>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Romain Geissler <romain dot geissler at amadeus dot com>, binutils at sourceware dot org
- Date: Sat, 14 Nov 2015 20:01:08 -0500
- Subject: Re: [Proposed patch] Huge performance regression in ld -r since binutils >= 2.21
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LNX dot 2 dot 10 dot 1511061715270 dot 27094 at ncegcolnx273 dot nce dot amadeus dot net> <20151109021609 dot GI17177 at bubble dot grove dot modra dot org> <alpine dot LNX dot 2 dot 10 dot 1511090942340 dot 3815 at ncegcolnx273 dot nce dot amadeus dot net> <20151109104107 dot GK17177 at bubble dot grove dot modra dot org>
On Mon, Nov 09, 2015 at 09:11:07PM +1030, Alan Modra wrote:
> - Sections are combined in ways that lose code locality. eg. with
> -ffunction-sections, all C static functions called "setup" will be
> placed together.
I actually wondered/worried what happens when static functions with
the same name from multiple files are used with -ffunction-sections
and --gc-sections, when some are used but others are not. Would it
perhaps make sense for gcc to attach some sort of hash based on things
like the filename and function contents to the section name so that
these section names are unique? That would probably solve a lot of the
problems with ld -r, too, assuming -ffunction-sections is used.
Of course ld -r could also have an option to create _new_ sections
like this rather than merging sections.
Rich