[commit: ghc] wip/D694: Use 64bit relocations (d262519)

[git at git.haskell.org]

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

On branch  : wip/D694
Link       : http://ghc.haskell.org/trac/ghc/changeset/d2625192e56dbee1f320172c593c9f0653f72bb0/ghc

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

commit d2625192e56dbee1f320172c593c9f0653f72bb0
Author: Joachim Breitner <mail at joachim-breitner.de>
Date:   Mon Mar 2 22:24:36 2015 +0100

    Use 64bit relocations
    
    Summary:
    according to the comments, this was not possible with ancient (pre 2006) versions
    of binutils. Even Debian stable has newer versions since a whilte.
    
    Please have a close look if you know something about this; I basically removed
    code by looking at the code around it, but do not necessarily know what I am
    doing here.
    
    Test Plan: Run validate on Harbormaster
    
    Reviewers: austin
    
    Subscribers: thomie
    
    Differential Revision: https://phabricator.haskell.org/D694


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

d2625192e56dbee1f320172c593c9f0653f72bb0
 compiler/nativeGen/X86/CodeGen.hs | 11 +----------
 compiler/nativeGen/X86/Ppr.hs     | 24 +-----------------------
 includes/rts/storage/InfoTables.h | 14 --------------
 3 files changed, 2 insertions(+), 47 deletions(-)

diff --git a/compiler/nativeGen/X86/CodeGen.hs b/compiler/nativeGen/X86/CodeGen.hs
index 531213d..d797b80 100644
--- a/compiler/nativeGen/X86/CodeGen.hs
+++ b/compiler/nativeGen/X86/CodeGen.hs
@@ -2616,17 +2616,8 @@ genSwitch dflags expr ids
                                    JMP_TBL (OpReg tableReg) ids Text lbl
                            ]
                       _ ->
-                          -- HACK: On x86_64 binutils<2.17 is only able
-                          -- to generate PC32 relocations, hence we only
-                          -- get 32-bit offsets in the jump table. As
-                          -- these offsets are always negative we need
-                          -- to properly sign extend them to 64-bit.
-                          -- This hack should be removed in conjunction
-                          -- with the hack in PprMach.hs/pprDataItem
-                          -- once binutils 2.17 is standard.
                           e_code `appOL` t_code `appOL` toOL [
-                                   MOVSxL II32 op (OpReg reg),
-                                   ADD (intSize (wordWidth dflags)) (OpReg reg) (OpReg tableReg),
+                                   ADD (intSize (wordWidth dflags)) op (OpReg tableReg),
                                    JMP_TBL (OpReg tableReg) ids ReadOnlyData lbl
                            ]
   | otherwise
diff --git a/compiler/nativeGen/X86/Ppr.hs b/compiler/nativeGen/X86/Ppr.hs
index 7022e59..9d290f2 100644
--- a/compiler/nativeGen/X86/Ppr.hs
+++ b/compiler/nativeGen/X86/Ppr.hs
@@ -470,29 +470,7 @@ pprDataItem' dflags lit
                           <> int (fromIntegral
                               (fromIntegral (x `shiftR` 32) :: Word32))]
                   _ -> panic "X86.Ppr.ppr_item: no match for II64"
-               | otherwise ->
-                  [ptext (sLit "\t.quad\t") <> pprImm imm]
-              _
-               | target32Bit platform ->
-                  [ptext (sLit "\t.quad\t") <> pprImm imm]
-               | otherwise ->
-                  -- x86_64: binutils can't handle the R_X86_64_PC64
-                  -- relocation type, which means we can't do
-                  -- pc-relative 64-bit addresses. Fortunately we're
-                  -- assuming the small memory model, in which all such
-                  -- offsets will fit into 32 bits, so we have to stick
-                  -- to 32-bit offset fields and modify the RTS
-                  -- appropriately
-                  --
-                  -- See Note [x86-64-relative] in includes/rts/storage/InfoTables.h
-                  --
-                  case lit of
-                  -- A relative relocation:
-                  CmmLabelDiffOff _ _ _ ->
-                      [ptext (sLit "\t.long\t") <> pprImm imm,
-                       ptext (sLit "\t.long\t0")]
-                  _ ->
-                      [ptext (sLit "\t.quad\t") <> pprImm imm]
+              _ -> [ptext (sLit "\t.quad\t") <> pprImm imm]
 
         ppr_item _ _
                 = panic "X86.Ppr.ppr_item: no match"
diff --git a/includes/rts/storage/InfoTables.h b/includes/rts/storage/InfoTables.h
index 3890d49..250f7c7 100644
--- a/includes/rts/storage/InfoTables.h
+++ b/includes/rts/storage/InfoTables.h
@@ -16,23 +16,9 @@
    relative to the info pointer, so that we can generate
    position-independent code.
 
-   Note [x86-64-relative]
-   There is a complication on the x86_64 platform, where pointeres are
-   64 bits, but the tools don't support 64-bit relative relocations.
-   However, the default memory model (small) ensures that all symbols
-   have values in the lower 2Gb of the address space, so offsets all
-   fit in 32 bits.  Hence we can use 32-bit offset fields.
-
-   Somewhere between binutils-2.16.1 and binutils-2.16.91.0.6,
-   support for 64-bit PC-relative relocations was added, so maybe this
-   hackery can go away sometime.
    ------------------------------------------------------------------------- */
 
-#if x86_64_TARGET_ARCH
-#define OFFSET_FIELD(n) StgHalfInt n; StgHalfWord __pad_##n
-#else
 #define OFFSET_FIELD(n) StgInt n
-#endif
 
 /* -----------------------------------------------------------------------------
    Profiling info