[commit: ghc] master: codeGen: Remove binutils<2.17 hack, fixes T11758 (e3e2e49)

git at git.haskell.org git at git.haskell.org
Fri Aug 5 08:41:02 UTC 2016


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

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/e3e2e49a8f6952e1c8a19321c729c17b294d8c92/ghc

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

commit e3e2e49a8f6952e1c8a19321c729c17b294d8c92
Author: Alex Dzyoba <alex at dzyoba.com>
Date:   Thu Aug 4 13:42:21 2016 +0200

    codeGen: Remove binutils<2.17 hack, fixes T11758
    
    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


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

e3e2e49a8f6952e1c8a19321c729c17b294d8c92
 compiler/nativeGen/X86/CodeGen.hs | 15 +--------------
 compiler/nativeGen/X86/Ppr.hs     | 23 ++---------------------
 includes/rts/storage/InfoTables.h | 11 -----------
 3 files changed, 3 insertions(+), 46 deletions(-)

diff --git a/compiler/nativeGen/X86/CodeGen.hs b/compiler/nativeGen/X86/CodeGen.hs
index cd45d92..2bfcd9a 100644
--- a/compiler/nativeGen/X86/CodeGen.hs
+++ b/compiler/nativeGen/X86/CodeGen.hs
@@ -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)
diff --git a/compiler/nativeGen/X86/Ppr.hs b/compiler/nativeGen/X86/Ppr.hs
index 7809ae1..090ff53 100644
--- a/compiler/nativeGen/X86/Ppr.hs
+++ b/compiler/nativeGen/X86/Ppr.hs
@@ -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"
diff --git a/includes/rts/storage/InfoTables.h b/includes/rts/storage/InfoTables.h
index fb14ac5..e6bd15c 100644
--- a/includes/rts/storage/InfoTables.h
+++ b/includes/rts/storage/InfoTables.h
@@ -15,17 +15,6 @@
    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



More information about the ghc-commits mailing list