Commit e96f56a1 authored by sof's avatar sof
Browse files

[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.
parent 4ab21614
...@@ -2222,9 +2222,15 @@ ocResolve_PEi386 ( ObjectCode* oc ) ...@@ -2222,9 +2222,15 @@ ocResolve_PEi386 ( ObjectCode* oc )
-- hence the constant 4. -- hence the constant 4.
Also I don't know if A should be added, but so Also I don't know if A should be added, but so
far it has always been zero. 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 + A;
*pP = S - ((UInt32)pP) - 4;
break; break;
default: default:
debugBelch("%s: unhandled PEi386 relocation type %d", debugBelch("%s: unhandled PEi386 relocation type %d",
......
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