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

> 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

On Thu, Oct 27, 2016 at 05:12:53PM -0400, John Reagan via llvm-dev
wrote:
> 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.
Actually, it is only GOT and PLT that is really relevant. All the other
data is easy to access via GOT with the same or less overhead than doing
the 64bit movabs dance. Some platforms like PPC allow multiple GOT and
PLT sections to deal with the immediate constraints of the platform.

Given that the PLT has to be executable, there is normally no big
justification for splitting it from the actual code segment. The GOT is
a bit more difficult, but I still don't see why you want to split that
off? The pain is large for mandating that to be separate.

Joerg