[lld] r332038 - Mitigate relocation overflow [part 1 of 2].

[Han Shen via llvm-commits]

Hi Peter, thanks.

On Mon, May 14, 2018 at 7:04 AM Peter Smith <peter.smith at linaro.org> wrote:

> Hello Han,

> I've no objections to changing the order of sections within the RO
> output section myself. I've put a few small comments inline:

> On 10 May 2018 at 21:44, Han Shen via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> > Author: shenhan
> > Date: Thu May 10 13:44:42 2018
> > New Revision: 332038
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=332038&view=rev
> > Log:
> > Mitigate relocation overflow [part 1 of 2].
> >
> > This CL is to mitigate R_X86_64_PC32 relocation overflow problems for
huge binaries that has near 4G allocated sections.
> >

> I'm guessing these are binaries where -mcmodel=small from
> R_X86_64_PC32? My understanding from intel's documentation is that
> mcmodel=small on x86 requires the code and data to be within 2G? Did
> you mean 2G allocated sections?

Ha yes, acknowledged, it should be "2G".

> > +  // Place .dynsym and .dynstr at the beginning of SHF_ALLOC
> > +  // sections. We want to do this to mitigate the possibility that
> > +  // huge .dynsym and .dynstr sections placed between text sections
> > +  // cause relocation overflow.  Note: .dynstr has SHT_STRTAB type and
> > +  // SHF_ALLOC attribute, whereas sections that only have SHT_STRTAB
> > +  // but without SHF_ALLOC is placed at the end. All "Sec" reaching
> > +  // here has SHF_ALLOC bit set.
> > +  if (Sec->Type == SHT_DYNSYM || Sec->Type == SHT_STRTAB)
> > +    return Rank | RF_ALLOC_FIRST;
> > +

> May I suggest "We want to do this to mitigate the possibility that
> huge .dynsym and .dynstr sections placed between ro-data and text
> sections cause relocation overflow." as the .dynsym and .dynstr won't
> be placed in between text sections.

Yes, acknowledged.


> Peter

I'll modify the CL (together with other comments from George) shortly,
thanks again for reviewing.

Han