MCJIT: relocation addends encoded in the target aren't quite so easy.
authorJim Grosbach <grosbach@apple.com>
Thu, 13 Sep 2012 01:24:37 +0000 (01:24 +0000)
committerJim Grosbach <grosbach@apple.com>
Thu, 13 Sep 2012 01:24:37 +0000 (01:24 +0000)
The assumption that the target address for the relocation will always be
sizeof(intptr_t) and will always contain an addend for the relocation
value is very wrong. Default to no addend for now.

rdar://12157052

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163765 91177308-0d34-0410-b5e6-96231b3b80d8

lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp

index 4fd7bc99c366f723b9fee800b6d1bd7aca77a1f0..465e85d7d91941335dce0c739318b62c5b7743e2 100644 (file)
@@ -246,7 +246,12 @@ void RuntimeDyldMachO::processRelocationRef(const ObjRelocationInfo &Rel,
     }
     assert(si != se && "No section containing relocation!");
     Value.SectionID = findOrEmitSection(Obj, *si, true, ObjSectionToID);
-    Value.Addend = *(const intptr_t *)Target;
+    Value.Addend = 0;
+    // FIXME: The size and type of the relocation determines if we can
+    // encode an Addend in the target location itself, and if so, how many
+    // bytes we should read in order to get it. We don't yet support doing
+    // that, and just assuming it's sizeof(intptr_t) is blatantly wrong.
+    //Value.Addend = *(const intptr_t *)Target;
     if (Value.Addend) {
       // The MachO addend is an offset from the current section.  We need it
       // to be an offset from the destination section