Allocate bss section within proper range of other sections

Allocate bss section within proper range of other sections:

* when `+RTS -xp` is passed, allocate it contiguously as we did for
  jump islands
* when we mmap the code to lower 2Gb, we should allocate bss section
  there too

This depends on {D5195}

Test Plan:
1. `./validate`

2.

with

```
DYNAMIC_GHC_PROGRAMS = NO
DYNAMIC_BY_DEFAULT = NO
```

`TEST="T15729" make test` passed in both linux and macos.

3.

Also test in a use case where we used to encouter error like:

```
ghc-iserv-prof: R_X86_64_PC32 relocation out of range: (noname) =
b90282ba
```

and now, everything works fine.

Reviewers: simonmar, bgamari, angerman, erikd

Reviewed By: simonmar

Subscribers: rwbarton, carter

GHC Trac Issues: #15729

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

1 files changed, 12 insertions, 10 deletions

diff --git a/rts/Linker.c b/rts/Linker.c
index b42a0de9c3..48d52c3f3d 100644
--- a/rts/Linker.c
+++ b/rts/Linker.c
@@ -1284,6 +1284,8 @@ mkOc( pathchar *path, char *image, int imageSize,
 #if defined(NEED_SYMBOL_EXTRAS)
    oc->symbol_extras     = NULL;
 #endif
+   oc->bssBegin          = NULL;
+   oc->bssEnd            = NULL;
    oc->imageMapped       = mapped;
 
    oc->misalignment      = misalignment;
@@ -1497,35 +1499,35 @@ HsInt loadOc (ObjectCode* oc)
    }
 
    /* Note [loadOc orderings]
-      The order of `ocAllocateSymbolExtras` and `ocGetNames` matters. For MachO
+      The order of `ocAllocateExtras` and `ocGetNames` matters. For MachO
       and ELF, `ocInit` and `ocGetNames` initialize a bunch of pointers based
-      on the offset to `oc->image`, but `ocAllocateSymbolExtras` may relocate
+      on the offset to `oc->image`, but `ocAllocateExtras` may relocate
       the address of `oc->image` and invalidate those pointers. So we must
-      compute or recompute those pointers after `ocAllocateSymbolExtras`.
+      compute or recompute those pointers after `ocAllocateExtras`.
 
       On Windows, when we have an import library we (for now, as we don't honor
       the lazy loading semantics of the library and instead GHCi is already
       lazy) don't use the library after ocGetNames as it just populates the
-      symbol table.  Allocating space for jump tables in ocAllocateSymbolExtras
+      symbol table.  Allocating space for jump tables in ocAllocateExtras
       would just be a waste then as we'll be stopping further processing of the
       library in the next few steps. If necessary, the actual allocation
-      happens in `ocGetNames_PEi386` and `ocAllocateSymbolExtras_PEi386` simply
+      happens in `ocGetNames_PEi386` and `ocAllocateExtras_PEi386` simply
       set the correct pointers.
       */
 
 #if defined(NEED_SYMBOL_EXTRAS)
 #  if defined(OBJFORMAT_MACHO)
-   r = ocAllocateSymbolExtras_MachO ( oc );
+   r = ocAllocateExtras_MachO ( oc );
    if (!r) {
        IF_DEBUG(linker,
-                debugBelch("loadOc: ocAllocateSymbolExtras_MachO failed\n"));
+                debugBelch("loadOc: ocAllocateExtras_MachO failed\n"));
        return r;
    }
 #  elif defined(OBJFORMAT_ELF)
-   r = ocAllocateSymbolExtras_ELF ( oc );
+   r = ocAllocateExtras_ELF ( oc );
    if (!r) {
        IF_DEBUG(linker,
-                debugBelch("loadOc: ocAllocateSymbolExtras_ELF failed\n"));
+                debugBelch("loadOc: ocAllocateExtras_ELF failed\n"));
        return r;
    }
 #  endif
@@ -1546,7 +1548,7 @@ HsInt loadOc (ObjectCode* oc)
    }
 
 #  if defined(OBJFORMAT_PEi386)
-   ocAllocateSymbolExtras_PEi386 ( oc );
+   ocAllocateExtras_PEi386 ( oc );
 #  endif
 #endif