Use 64bit relocationswip/D694

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

3 files changed, 2 insertions, 47 deletions

diff --git a/compiler/nativeGen/X86/CodeGen.hs b/compiler/nativeGen/X86/CodeGen.hs
index 531213dc7f..d797b8014c 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 7022e59647..9d290f299c 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 3890d49a8e..250f7c76d7 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