This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [gold] Merging string literals with bigger alignment
The testcase in the patch from my first letter has those .c files. But
it's very simple anyway:
>cat merge_string_literals_1.c
const char* bar1() {
return "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
}
const char* bar1_short() {
return "SSSSSS";
}
>gcc -c merge_string_literals_1.c -O2
>readelf -S merge_string_literals_1.o | grep rodata
[ 5] .rodata.str1.8 PROGBITS 0000000000000000 00000058
[ 6] .rodata.str1.1 PROGBITS 0000000000000000 0000007d
>objdump -s -j.rodata.str1.8 merge_string_literals_1.o
merge_string_literals_1.o: file format elf64-x86-64
Contents of section .rodata.str1.8:
0000 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
0010 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
0020 41414141 00 AAAA.
I mentioned .rodata.str1.4 before - that could happen if we compile
for 32 bits..
thank you,
Alexander
2013/2/12 Ian Lance Taylor <iant@google.com>:
> On Tue, Feb 12, 2013 at 6:22 AM, Alexander Ivchenko <aivchenk@gmail.com> wrote:
>> 2013/2/8 Ian Lance Taylor <iant@google.com>:
>>>
>>> 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?
>
> I don't think you are missing anything. That is why I wrote the
> comment "This could be handled, but it's unusual." Although
> apparently it is not unusual.
>
>>> 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..
>
> Can you show us a smal source code example that will cause GCC to
> produce such a section? Thanks.
>
> Ian