Re: Map ".text.hot" and ".text.unlikely" input section prefixes to separate output sections.

[Sriraman Tallam <tmsriram at google dot com>]

Hi Ian,

On Fri, Nov 16, 2012 at 5:19 PM, Ian Lance Taylor <iant@google.com> wrote:
> On Wed, Nov 14, 2012 at 5:06 PM, Sriraman Tallam <tmsriram@google.com> 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
> using.
>
> 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
>>> Input_section_list.
>
> 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.

Do you mean looking up the entire input section name or just the
interesting prefix? If it is the entire name I do not fully follow how
this would group sections with the same prefix.

If it is just the prefix, I think the issue with this approach is what
to look for in the hash table when presented with a section name. Lets
say function foo is in section ".text.hot.foo.isra.4". How do we tell
".text.hot" is interesting and not ".text.hot.foo.isra" quickly?,
without having to look up the hash table multiple times.

Thanks,
-Sri.


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.
>
> Ian