This is the mail archive of the
mailing list for the binutils project.
Re: Map ".text.hot" and ".text.unlikely" input section prefixes to separate output sections.
- From: Ian Lance Taylor <iant at google dot com>
- To: Sriraman Tallam <tmsriram at google dot com>
- Cc: binutils <binutils at sourceware dot org>, Cary Coutant <ccoutant at google dot com>
- Date: Fri, 16 Nov 2012 17:19:01 -0800
- Subject: Re: Map ".text.hot" and ".text.unlikely" input section prefixes to separate output sections.
- References: <CAAs8HmygtSkVh3v4dz2hBTzS1AH-rLbBkTDJ-hVkzENC2sqQZg@mail.gmail.com> <email@example.com> <CAAs8HmxS9v50Bzw1srgUaC+8dCekCjv_H5_kyAi3Z5TDB8TkGg@mail.gmail.com>
On Wed, Nov 14, 2012 at 5:06 PM, Sriraman Tallam <firstname.lastname@example.org> wrote:
> I finally got around to doing this in a way you suggested a while
> back, that is sorting text sections within the output section rather
> than creating separate output sections. Patch attached.
That is clever, and I admit it is more or less what GNU ld does, but I
don't think it's the right approach. I don't want us to have to add a
special case to the linker every time somebody thinks of a new idea in
the compiler--that is the problem with the approach that GNU ld is
I would rather do this:
>> Ideally gold should group all input sections with the same name
>> together, regardless of what output section they are going to. I
>> believe this can be done in Output_section::add_input_section if we
>> preserve the name in Input_section_list. The main drawback is that this
>> may mean giving up on the current optimization of not building an
Here is one way to do it. Add a hash table to Output_section mapping
input section names to section order indexes. in
Output_section::add_input_section, if the input section name is not
the same as the output section name, look up the input section name in
the new hash table. If it is there, use the section order index. If
it is not there, pick a new section order index, and insert it in the
hash table. Set the sort field as needed. Throw away all the hash
tables in Layout::finalize--we won't need them after that, and they
may be big.
If you implement this, please measure the effect on linker time for
some big files. if it is too slow we may not be able to do it.