From e96f56a17c815d1c6ee898433dd61ded9289f189 Mon Sep 17 00:00:00 2001 From: sof Date: Thu, 5 May 2005 18:14:27 +0000 Subject: [PATCH] [project @ 2005-05-05 18:14:27 by sof] ocResolve_PEi386(): when fixing up REL32 relocations, _add_ displacement to value at the given offset. The existing value has so far been assumed to be zero (which we've asserted for), but curiously wxhaskell-0.9.4's wx.o contains lots of interesting non-zero values. Information / specifications are awfully thin on the ground as to how to precisely handle these relocations, but adding rather than overwriting seems to have a generally healthy effect; unable to crash wxhaskell-0.9.4 with a 6.4 build. Merge to STABLE. --- ghc/rts/Linker.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/ghc/rts/Linker.c b/ghc/rts/Linker.c index 5d887f4..11e111a 100644 --- a/ghc/rts/Linker.c +++ b/ghc/rts/Linker.c @@ -2222,9 +2222,15 @@ ocResolve_PEi386 ( ObjectCode* oc ) -- hence the constant 4. Also I don't know if A should be added, but so far it has always been zero. + + SOF 05/2005: 'A' (old contents of *pP) have been observed + to contain values other than zero (the 'wx' object file + that came with wxhaskell-0.9.4; dunno how it was compiled..). + So, add displacement to old value instead of asserting + A to be zero. Fixes wxhaskell-related crashes, and no other + ill effects have been observed. */ - ASSERT(A==0); - *pP = S - ((UInt32)pP) - 4; + *pP = S - ((UInt32)pP) - 4 + A; break; default: debugBelch("%s: unhandled PEi386 relocation type %d", -- 1.7.10.4