This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [gold] Merging string literals with bigger alignment
- From: Alexander Ivchenko <aivchenk at gmail dot com>
- To: Cary Coutant <ccoutant at google dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, binutils <binutils at sourceware dot org>, Sriraman Tallam <tmsriram at google dot com>
- Date: Sun, 31 Mar 2013 17:08:30 +0400
- Subject: Re: [gold] Merging string literals with bigger alignment
- References: <CACysShhXDPxUsqdUprwhyGcaNiS9X_ODbrW847wHHiwbUh4LhA at mail dot gmail dot com> <CAKOQZ8xROxuJMD19P7JoM084LDyDKk_anwiuoWRpS+2MLeThnA at mail dot gmail dot com> <CACysShhaCv68A39oTk5FfmsdRFjhoOjQEzEZys4U0-sZs-x+4A at mail dot gmail dot com> <CAKOQZ8ypF=yCMmrwn-8jSp_WBMdrNi6NqwJRqabG7ZUwV2yMhg at mail dot gmail dot com> <CACysShhyE2G_8fz1pLSjTdJ_f9OYdSHHB9zvydWPaJNHjFkQ8g at mail dot gmail dot com> <CAKOQZ8wd_7bfSfMsm_WmJnSdT_J4qF-JM+3Ex=tU0iDJCOWETQ at mail dot gmail dot com> <CACysShh22grCuoa7-b3QV7D_Q-RBYrtLH8ifr2yRcS93+GRk1g at mail dot gmail dot com> <CAHACq4pqmPp7JqwOJ_Ux0NN7yVZzq82t4uf9ZUKTa8eXL+Znrg at mail dot gmail dot com> <CACysShjRoZMEp=JasvdY9Jg=+ab15FEEUY-WnR-4dLb9q+C-Cg at mail dot gmail dot com> <CAHACq4rEinAxU_5Cp7SQiNeZN8tZsbp-YCwbuzR-bC5Z9GOrJw at mail dot gmail dot com> <CACysShh_8waYTA4tQWGnRER5xrwv=NgSn2NRhzOLfncPuOeOsg at mail dot gmail dot com> <CAHACq4odyq1ok_SWBFNUDreq8=b-4MMqp3DXJY03viF2-HUe8w at mail dot gmail dot com>
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