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

John Reagan via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 31 11:30:43 PDT 2016

Message: 2 Date: Sat, 29 Oct 2016 22:36:41 +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: <20161029203641.GB20270 at britannica.bec.de> Content-Type: text/plain; charset=us-ascii 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

OpenVMS on both Alpha and Itanium are mixed-sized pointer systems. The default size is 32-bits but there are also 64-bit interfaces.

Some of our languages have 64-bit pointers, but some do not. They still are VAX-era languages which believe you can hold a pointer to a routine in a 32-bit longword. To have code actually in 64-bit address space, the way we implement this on Itanium is to keep the function descriptors and short section in 32-bit space. The address of a "routine" is the address of its function descriptor since you need both the code address and the GP value to call the routine. (Yes, our linker does something slightly non-standard with the DIR32LSB/DIR64LSB relocations by treating them as FPTR32LSB/FPTR64LSB for STT_FUNCs so you can actually never obtain the code address via linker relocation).

The idea to make this all work on x86-64 is to use the address of a routine's PLT as its "address" in all cases. By putting the PLT in 32-bit address space, some ancient BASIC or Fortran program can continue to use an INTEGER*4 to hold a routine's "address" and pass it around. Of course, our PLTs won't be actual dynamic loading code but just trampolines to the 64-bit code. The PLTs provide a consistent "address of routine" for pointer comparisons, etc just like the "primary function descriptor" on Itanium.

John

More information about the llvm-dev mailing list