Add a RTS option -xp to load PIC object anywhere in address space

Summary:
This re-applies {D5195} with fixes for i386:
* Fix unused label warnings, see {D5230} or {D5273}
* Fix a silly bug introduced by moving `#if`

{P190}

Add a RTS option -xp to load PIC object anywhere in address space. We do
this by relaxing the requirement of <0x80000000 result of
`mmapForLinker` and implying USE_CONTIGUOUS_MMAP.

We also need to change calls to `ocInit` and `ocGetNames` to avoid
dangling pointers when the address of `oc->image` is changed by
`ocAllocateSymbolExtra`.

Test Plan:
See {D5195}, also test under i386:

```
$ uname -a
Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28
20:45:30 CEST 2018 i686 GNU/Linux
$ cd testsuite/tests/th/ && make test
...
```

will run `./validate` on stacked diff.

Reviewers: simonmar, bgamari, alpmestan, trommler, hvr, erikd

Reviewed By: simonmar

Subscribers: rwbarton, carter

Differential Revision: https://phabricator.haskell.org/D5289

2 files changed, 30 insertions, 2 deletions

diff --git a/docs/users_guide/8.8.1-notes.rst b/docs/users_guide/8.8.1-notes.rst
index cd4c00d1a4..33b7f48e43 100644
--- a/docs/users_guide/8.8.1-notes.rst
+++ b/docs/users_guide/8.8.1-notes.rst
@@ -111,6 +111,10 @@ Runtime system
   Generation of these files, which sport a ``.hie`` suffix, is enabled via the
   ``-fwrite-ide-info`` flag. See :ref:`hie-options` for more information.
 
+- A new flag ``-xp`` is added on x86_64. When it is passed, the runtime linker
+  can load object files compiled with ``-fPIC -fexternal-dynamic-refs``
+  anywhere in the address space. This used to be restricted to the low 2Gb.
+
 Template Haskell
 ~~~~~~~~~~~~~~~~
 
diff --git a/docs/users_guide/runtime_control.rst b/docs/users_guide/runtime_control.rst
index a5c2f1474f..0048a51837 100644
--- a/docs/users_guide/runtime_control.rst
+++ b/docs/users_guide/runtime_control.rst
@@ -241,6 +241,28 @@ Miscellaneous RTS options
     crashes if exception handling are enabled. In order to get more information
     in compiled executables, C code or DLLs symbols need to be available.
 
+
+.. rts-flag:: -xp
+
+    On 64-bit machines, the runtime linker usually needs to map object code
+    into the low 2Gb of the address space, due to the x86_64 small memory model
+    where most symbol references are 32 bits. The problem is that this 2Gb of
+    address space can fill up, especially if you're loading a very large number
+    of object files into GHCi.
+
+    This flag offers a workaround, albeit a slightly convoluted one. To be able
+    to load an object file outside of the low 2Gb, the object code needs to be
+    compiled with ``-fPIC -fexternal-dynamic-refs``. When the ``+RTS -xp`` flag
+    is passed, the linker will assume that all object files were compiled with
+    ``-fPIC -fexternal-dynamic-refs`` and load them anywhere in the address
+    space. It's up to you to arrange that the object files you load (including
+    all packages) were compiled in the right way. If this is not the case for
+    an object, the linker will probably fail with an error message when the
+    problem is detected.
+
+    On some platforms where PIC is always the case, e.g. x86_64 MacOS X, this
+    flag is enabled by default.
+
 .. rts-flag:: -xm ⟨address⟩
 
     .. index::
@@ -250,8 +272,10 @@ Miscellaneous RTS options
 
         This option is for working around memory allocation
         problems only. Do not use unless GHCi fails with a message like
-        “\ ``failed to mmap() memory below 2Gb``\ ”. If you need to use this
-        option to get GHCi working on your machine, please file a bug.
+        “\ ``failed to mmap() memory below 2Gb``\ ”. Consider recompiling
+        the objects with ``-fPIC -fexternal-dynamic-refs`` and using the
+        ``-xp`` flag instead. If you need to use this option to get GHCi
+        working on your machine, please file a bug.
 
     On 64-bit machines, the RTS needs to allocate memory in the low 2Gb
     of the address space. Support for this across different operating