[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