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

[Peter Smith via llvm-commits]

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?

> +  // 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.

Peter