codeGen: Remove binutils<2.17 hack, fixes T11758
authorAlex Dzyoba <alex@dzyoba.com>
Thu, 4 Aug 2016 11:42:21 +0000 (13:42 +0200)
committerBen Gamari <ben@smart-cactus.org>
Fri, 5 Aug 2016 08:40:45 +0000 (10:40 +0200)
There was a complication on the x86_64 platform, where pointers were 64
bits, but the tools didn't support 64-bit relative relocations.  This
was true before binutils 2.17, which nowadays is quite standart (even
CentOs 5 is shipped with 2.17).

Hacks were removed from x86 genSwitch and asm pretty printer. Also
[x86-64-relative] note was dropped from
includes/rts/storage/InfoTables.h as it's not referenced anywhere now.

Reviewers: austin, simonmar, rwbarton, erikd, bgamari

Reviewed By: simonmar, erikd, bgamari

Subscribers: thomie

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

compiler/nativeGen/X86/CodeGen.hs
compiler/nativeGen/X86/Ppr.hs
includes/rts/storage/InfoTables.h

index cd45d92..2bfcd9a 100644 (file)
@@ -2624,23 +2624,10 @@ genSwitch dflags expr targets
         let op = OpAddr (AddrBaseIndex (EABaseReg tableReg)
                                        (EAIndex reg (wORD_SIZE dflags)) (ImmInt 0))
 
-        return $ if is32bit || os == OSDarwin
-                 then e_code `appOL` t_code `appOL` toOL [
+        return $ e_code `appOL` t_code `appOL` toOL [
                                 ADD (intFormat (wordWidth dflags)) op (OpReg tableReg),
                                 JMP_TBL (OpReg tableReg) ids rosection lbl
                        ]
-                 else -- 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 (intFormat (wordWidth dflags)) (OpReg reg)
-                                   (OpReg tableReg),
-                               JMP_TBL (OpReg tableReg) ids rosection lbl
-                       ]
   | otherwise
   = do
         (reg,e_code) <- getSomeReg (cmmOffset dflags expr offset)
index 7809ae1..090ff53 100644 (file)
@@ -454,27 +454,8 @@ pprDataItem' dflags lit
                   _ -> panic "X86.Ppr.ppr_item: no match for II64"
                | otherwise ->
                   [text "\t.quad\t" <> pprImm imm]
-              _
-               | target32Bit platform ->
-                  [text "\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 _ _ _ ->
-                      [text "\t.long\t" <> pprImm imm,
-                       text "\t.long\t0"]
-                  _ ->
-                      [text "\t.quad\t" <> pprImm imm]
+
+              _ -> [text "\t.quad\t" <> pprImm imm]
 
         ppr_item _ _
                 = panic "X86.Ppr.ppr_item: no match"
index fb14ac5..e6bd15c 100644 (file)
    Several pointer fields in info tables are expressed as offsets
    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 pointers 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