[llvm-dev] PIC and mcmodel=large on x86 doesn't use any relocations

[John Reagan via llvm-dev]

> Message: 4
> Date: Thu, 27 Oct 2016 22:04:28 +0200
> From: Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] PIC and mcmodel=large on x86 doesn't use any
> 	relocations
> Message-ID: <20161027200428.GA2177 at britannica.bec.de>
> Content-Type: text/plain; charset=us-ascii
> 
> On Thu, Oct 27, 2016 at 02:42:54PM -0400, John Reagan via llvm-dev
> wrote:
> > We're at the point in our port of OpenVMS to x86 using LLVM to make
> > choices on mcmodel.  Given OpenVMS's history, our linker will
> allocate
> > static data (ie, .data, .bss, .plt, GOT, etc.) in the bottom 32-bits
> > of address space (ie, 00000000.xxxxxxxx).  However, we support code
> > anywhere in the 64-bit address space as PIC code (we do this on
> > Itanium today using our own code-generator and linker).  Given this
> > requirement, I'm looking at the support for -fPIC and -mcmodel=large.
> > Either I'm missing something or there is something broken (and has
> been for quite a while).
> 
> I don't think we support the large code model on amd64 for anything but
> JIT use. I'm generally not sure how much point there really is. Do you
> actually have individual share objects larger than 2GB? It's not a
> problem to have multiple DSOs that span much more than 2GB, but doing
> that inside a single object is very expensive.
> 
> Joerg
> 

I want my GOT, .plt, and other static data to be more than 2GB away from the code.
Our stack and heap will also live in the bottom 2GB chunk of memory due to VAX
history.

No single code segment or data segment will be larger than 2GB however.  So
branches inside of .text for example (or to other code sections) will fit
within 2GB.

John