Re: [gold] Merging string literals with bigger alignment

[Cary Coutant <ccoutant at google dot com>]

> But isn't that defined that if the string is placed in, say,
> rodata.1.8 section, than
> we can count that its alignment is 8? If the user doesn't want that string to
> be 8-aligned or wants  4 modulo 8 then he\she should not put that string in
> 8-aligned section. As far as I understand BFD merge code is not checking that
> (why should it?) and we are compatible

In a non-merge section, the internal alignments are preserved simply
by preserving the beginning alignment. In a merge section, that's not
going to happen automatically, so it should either be detected as an
error or handled in a natural way. I'm not saying we should support it
-- if you've got a .rodata.1.8 SHF_MERGE section, it's reasonable to
assume that all strings within the section would be aligned. But what
if the compiler does something strange, or makes a contrary
assumption? If we accept the convention that all strings in the
section should be aligned, I think it would be a good idea to insert a
simple check into the code and print an error message. I think the BFD
linker should do that, too.

Also, when processing the section in
Output_merge_string::do_add_input_section, we count the strings in the
section essentially by counting the null characters. This will count
each padding byte as a separate string, so we'll get an inflated
estimate of the number of strings. If we accept the above convention,
the compiler should never point to any of these (unaligned) padding
bytes as a null string, so we shouldn't need to count them or call
add_with_length_and_alignment for all those null strings. In other
words, once we add a string, we should skip ahead to the next
alignment boundary.

-cary