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/3/28 Cary Coutant <ccoutant@google.com>:
> +  // We assume here that the beginning of the section is correctly
> +  // aligned, so each string within the section must retain the same
> +  // modulo.
> +  uint64_t init_align_modulo = (uint64_t) pdata % this->addralign();
>
> The view you're looking at will already be aligned correctly, so I
> don't think this is necessary (i.e., init_align_modulo will always be
> 0).

No, that could not be true, because, as far as I understand, pdata
here points at our internal storage that
does not have to comply with the alignment requirements. So all we can
do here is to assume that its alignment
is correct and then check the alignment of each string within this
section relatively to that initial modulo.
(I encounter that when pdata for .rodata.str1.16 section from libc.a
had 8 alignment, but, of course, that section
itself in libc.a was correctly 16-aligned)


> I think you'll also need to change
> Stringpool_template<Stringpool_char>::Stringpool_eq::operator() to
> check the alignment that you've stored in the Hashkey. Imagine one
> section that adds a string with alignment 1, and a subsequent section
> that adds the same string with alignment 4 -- when adding the string
> the second time, you'll match the first, and keep the 1-byte
> alignment. Ideally, you'd just update the alignment so there's only
> one copy of the string at the larger alignment, but that will only
> work if you're optimizing the string tables (-O2).

I know that now two equal strings with different alignments will not
be merged (BFD also does not merge them together).
But to improve that we also need to change
Merge_section_properties::eq() so mergable string sections with
different alignments
would fall into the same Output_merge_string_data (we also need to
accordingly update some asserts, hash function for
Merge_section_properties etc.).
Since BFD doesn't do it, I want to make it as a separate subsequent
patch, if you don't mind of course..

thanks again for your input,
Alexander


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