x86-64: fix a problem exposed by negative offsets in vector tables

static relative offsets (eg .long l1-l2) are restricted to 32 bits on
x86-64 due to lack of support in the linker.  The codegen, NCG and
runtime work around this, using 32-bit offsets instead of 64.
However, we were missing a workaround for vector tables, and it
happened to work by accident because the offsets were always positive
and resolved by the assembler.  The bug was exposed by using the NCG
to compile the RTS, where the offsets became negative, again by
accident.

diff --git a/compiler/codeGen/CgInfoTbls.hs b/compiler/codeGen/CgInfoTbls.hs
index b769950..5a40a3d 100644 (file)
--- a/compiler/codeGen/CgInfoTbls.hs
+++ b/compiler/codeGen/CgInfoTbls.hs
@@ -51,7 +51,7 @@ import CgMonad
 import CmmUtils                ( mkIntCLit, zeroCLit )
 import Cmm             ( CmmStmt(..), CmmExpr(..), CmmLit(..), LocalReg,
                          CmmBasicBlock, nodeReg )
-import MachOp          ( MachOp(..), wordRep, halfWordRep )
+import MachOp
 import CLabel
 import StgSyn          ( SRT(..) )
 import Name            ( Name )
@@ -217,7 +217,14 @@ retVec :: CmmExpr -> CmmExpr -> CmmExpr
 -- Get a return vector from the info pointer
 retVec info_amode zero_indexed_tag
   = let slot = vectorSlot info_amode zero_indexed_tag
+#ifdef x86_64_TARGET_ARCH
+        tableEntry = CmmMachOp (MO_S_Conv I32 I64) [CmmLoad slot I32]
+       -- offsets are 32-bits on x86-64, due to the inability of
+       -- the tools to handle 64-bit PC-relative relocations.  See also
+       -- PprMach.pprDataItem, and InfoTables.h:OFFSET_FIELD().
+#else
         tableEntry = CmmLoad slot wordRep
+#endif
     in if tablesNextToCode
            then CmmMachOp (MO_Add wordRep) [tableEntry, info_amode]
            else tableEntry