This is the mail archive of the
mailing list for the binutils project.
Re: [gold] Merging string literals with bigger alignment
- From: Ian Lance Taylor <iant at google dot com>
- To: Alexander Ivchenko <aivchenk at gmail dot com>
- Cc: binutils <binutils at sourceware dot org>, Sriraman Tallam <tmsriram at google dot com>
- Date: Fri, 8 Feb 2013 06:46:37 -0800
- Subject: Re: [gold] Merging string literals with bigger alignment
- References: <CACysShhXDPxUsqdUprwhyGcaNiS9X_ODbrW847wHHiwbUh4LhA@mail.gmail.com>
On Fri, Feb 8, 2013 at 5:21 AM, Alexander Ivchenko <firstname.lastname@example.org> 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
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?