PIC and mcmodel=large on x86 doesn't use any relocations

Project Infrastructure LLVM Dev List Archives
1

Message: 4
Date: Thu, 27 Oct 2016 22:04:28 +0200
From: Joerg Sonnenberger via llvm-dev <llvm-dev@lists.llvm.org>
To: llvm-dev@lists.llvm.org
Subject: Re: [llvm-dev] PIC and mcmodel=large on x86 doesn't use any
  relocations
Message-ID: <20161027200428.GA2177@britannica.bec.de>
Content-Type: text/plain; charset=us-ascii

> 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

2

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