lld: 2MB- or 4MB-aligned .text

[Rui Ueyama via llvm-commits]

On Tue, Nov 22, 2016 at 11:25 AM, Ed Maste via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On x86-64 it's beneficial to align the text segment it to 2MB, then
> the FreeBSD kernel can automatically promote the mapping to a 2MB
> superpage. On most architectures both GNU ld and gold put the text
> segment at 0x400000 so this can happen, while lld defaults to 0x10000.
>
> I'm guessing that the GNU linker developers ended up with 4MB as the
> lowest common multiple of large page sizes on common platforms and
> just used the same value in all of those cases, although AFAICT 2MB
> would be just as good on x86-64. In typical GNU changelog style the
> description for the change that increased it to 4MB (from 4K
> previously) is:
>
> * elf_x86_64.sh (NONPAGED_TEXT_START_ADDR): Increase.
>   (TEXT_START_ADDR): Likewise.
>

This changelog is too awesome...


> Is there a reason we shouldn't start the text segment at 0x400000 as well?
>
> --- a/ELF/Target.h
> +++ b/ELF/Target.h
> @@ -70,7 +70,7 @@ public:
>    // Given that, the smallest value that can be used in here is 0x10000.
>    // If using 2MB pages, the smallest page aligned address that works is
>    // 0x200000, but it looks like every OS uses 4k pages for executables.
> -  uint64_t DefaultImageBase = 0x10000;
> +  uint64_t DefaultImageBase = 0x400000;
>

The reason why the current value is 0x10000 is described here, and that
makes me wonder why it cannot be 0x200000 instead of 0x400000. Did you mean
that there's an architecture that has 4MB page instead of 2MB?

   uint32_t CopyRel;
>    uint32_t GotRel;
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161122/ea9fe872/attachment.html>