Re: [gold] Merging string literals with bigger alignment

[Alexander Ivchenko <aivchenk at gmail dot com>]

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