[PATCH] D31649: [mips] Adds support for R_MIPS_26, HIGHER, HIGHEST relocations in RuntimeDyld

Sagar Thakur via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 9 02:20:37 PDT 2017


slthakur added inline comments.


================
Comment at: lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:1394-1414
+      int64_t Addend = Value.Addend + SignExtend32<16>(Opcode & 0x0000ffff);
+      for (auto I = PendingRelocs.begin(); I != PendingRelocs.end();) {
+        const RelocationValueRef &MatchingValue = I->first;
+        RelocationEntry &Reloc = I->second;
+        if (MatchingValue == Value &&
+            RelType == getMatchingLoRelocation(Reloc.RelType) &&
+            SectionID == Reloc.SectionID) {
----------------
sdardis wrote:
> I don't think this is correct for HIGHER/HIGHEST/HI/LO. You're creating two relocation entries for a symbol/section. One containing the HIGHEST+HIGHER part of the addend and the other the HI+HO. Shouldn't R_MIPS_HIGHER get pushed back as well and add the RelocationEntry after computing the addend from all four relocations?
Actually these relocations are filled in the .rela section for n32/n64 which has a separate addend field. Do we need to do this pair matching for the calculation of the addend?


Repository:
  rL LLVM

https://reviews.llvm.org/D31649





More information about the llvm-commits mailing list