This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gold] Merging string literals with bigger alignment


2013/2/8 Ian Lance Taylor <iant@google.com>:
> On Fri, Feb 8, 2013 at 5:21 AM, Alexander Ivchenko <aivchenk@gmail.com> wrote:
>>
>> Both Intel compiler and GNU compiler put string literals into special
>> sections: .rodata.str1.X. ICC puts literals to .rodata.str1.4 and
>> .rodata.str1.32. GCC puts them to .rodata.str1.1 and .rodata.str1.4.
>> Gold linker merges strings only from .rodata.str1.1, BFD linker
>> processes all sections.
>>
>> Lost merging capability increased the size of the ICC+gold
>> libwebcore.so build in 1.5 times against the build with BFD. I believe
>> we can find the same results for GCC.
>>
>> Also it is needed for correct inline work: when function is inlined
>> into two different files, string literals that this function uses will
>> also be put into two different object files. Therefore the inlined
>> body of the function will use different string literals, which doesn't
>> sound correct.
>>
>> Seems that the only thing that blocks string literals from, say,
>> .rodata.str1.4 to be merged is this:
>>
>> // We only merge strings if the alignment is not more than the
>> // character size. This could be handled, but it's unusual.
>> if (is_string && addralign > entsize)
>> return false;
>>
>> I'm not sure what was the reason for this..
>
> If the requested alignment of the section is, say, 32, that implies
> that the first entry of the section must be aligned on a 32-byte
> boundary.  There must be some reason that the compiler is asking for
> that alignment.  The merge code in gold does not preserve the
> alignment.  Simply discarding the check means that we are ignoring the
> compiler's requested alignment.  That doesn't sound like a good idea
> to me.

Seems that we have to add the alignment preservation in the merge
code. Or am I missing something?

> Testing on x86 proves nothing as x86 has no alignment requirements.
>
> Why does icc request a larger alignment for a mergeable string
> section?  What does it want to have happen?

I'm not really sure about the exact reason of that. But we have an
issue with GCC as well, because string literals produced by GCC with
alignment 4 still are not merged now..

Alexander


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]