Commit e3e2e49a authored by avd's avatar avd Committed by Ben Gamari

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:
parent f09d6547
......@@ -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)
......@@ -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"
......@@ -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-,
support for 64-bit PC-relative relocations was added, so maybe this
hackery can go away sometime.
------------------------------------------------------------------------- */
#if x86_64_TARGET_ARCH
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment