[commit: ghc] ghc-8.0: Fix incorrect calculated relocations on Windows x86_64 (38497a2)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/ghc

On branch  : ghc-8.0
Link       : http://ghc.haskell.org/trac/ghc/changeset/38497a2317b015249c96d03c2c3df97fffdc6929/ghc

>---------------------------------------------------------------

commit 38497a2317b015249c96d03c2c3df97fffdc6929
Author: Tamar Christina <tamar at zhox.com>
Date:   Sat Jun 11 10:18:19 2016 +0200

    Fix incorrect calculated relocations on Windows x86_64
    
    Summary:
    See #12031 for analysis, but essentially what happens is:
    
    To sum up the issue, the reason this seems to go wrong is because
    of how we initialize the `.bss` section for Windows in the runtime linker.
    
    The first issue is where we calculate the zero space for the section:
    
    ```
    zspace = stgCallocBytes(1, bss_sz, "ocGetNames_PEi386(anonymous bss)");
    sectab_i->PointerToRawData = ((UChar*)zspace) - ((UChar*)(oc->image));
    ```
    
    Where
    ```
    UInt32 PointerToRawData;
    ```
    
    This means we're stuffing a `64-bit` value into a `32-bit` one. Also `zspace`
    can be larger than `oc->image`. In which case it'll overflow and
    then get truncated in the cast.
    
    The address of a value in the `.bss` section is then calculated as:
    
    ```
    addr = ((UChar*)(oc->image))
         + (sectabent->PointerToRawData
         + symtab_i->Value);
    ```
    
    If it does truncate then this calculation won't be correct (which is what is happening).
    
    We then later use the value of `addr` as the `S` (Symbol) value for the relocations
    
    ```
    S = (size_t) lookupSymbol_( (char*)symbol );
    ```
    
    Now the majority of the relocations are `R_X86_64_PC32` etc.
    e.g. They are guaranteed to fit in a `32-bit` value.
    
    The `R_X86_64_64` introduced for these pseudo-relocations so they can use
    the full `48-bit` addressing space isn't as lucky.
    As for why it sometimes work has to do on whether the value is truncated or not.
    
    `PointerToRawData` can't be changed because it's size is fixed by the PE specification.
    
    Instead just like with the other platforms, we now use `section` on Windows as well.
    This gives us a `start` parameter of type `void*` which solves the issue.
    
    This refactors the code to use `section.start` and to fix the issues.
    
    Test Plan: ./validate and new test added T12031
    
    Reviewers: RyanGlScott, erikd, bgamari, austin, simonmar
    
    Reviewed By: simonmar
    
    Subscribers: thomie, #ghc_windows_task_force
    
    Differential Revision: https://phabricator.haskell.org/D2316
    
    GHC Trac Issues: #12031, #11317
    
    (cherry picked from commit b40e1b4c6746bdc34e6a53548a3925d309201c4d)


>---------------------------------------------------------------

38497a2317b015249c96d03c2c3df97fffdc6929
 rts/Linker.c                             | 71 ++++++++++++++++++--------------
 rts/LinkerInternals.h                    |  4 +-
 testsuite/tests/rts/T12031/ExternBug.hs  |  9 ++++
 testsuite/tests/rts/T12031/Makefile      |  8 ++++
 testsuite/tests/rts/T12031/T12031.stdout |  1 +
 testsuite/tests/rts/T12031/all.T         |  2 +
 testsuite/tests/rts/T12031/bar.c         | 11 +++++
 testsuite/tests/rts/T12031/baz.c         |  9 ++++
 testsuite/tests/rts/T12031/foo.h         | 11 +++++
 9 files changed, 94 insertions(+), 32 deletions(-)

Diff suppressed because of size. To see it, use:

    git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc 38497a2317b015249c96d03c2c3df97fffdc6929