[RuntimeDyld] Make RuntimeDyldImpl::resolveExternalSymbols preserve the

relocation entries it applies.

Prior to this patch, RuntimeDyldImpl::resolveExternalSymbols discarded
relocations for external symbols once they had been applied. This causes issues
if the client calls MCJIT::finalizeLoadedModules more than once, and updates the
location of any symbols in between (e.g. by calling MCJIT::mapSectionAddress).

No test case yet: None of our in-tree memory managers support moving sections
around. I'll have to hack up a dummy memory manager before I can write a unit
test.

Fixes <rdar://problem/16764378>

llvm-svn: 208257
This commit is contained in:
Lang Hames 2014-05-07 22:34:08 +00:00
parent 9967f49a3c
commit fd284c6ce1
1 changed files with 14 additions and 0 deletions

View File

@ -620,6 +620,8 @@ void RuntimeDyldImpl::resolveRelocationList(const RelocationList &Relocs,
}
void RuntimeDyldImpl::resolveExternalSymbols() {
StringMap<RelocationList> ProcessedSymbols;
while (!ExternalSymbolRelocations.empty()) {
StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin();
@ -665,8 +667,20 @@ void RuntimeDyldImpl::resolveExternalSymbols() {
resolveRelocationList(Relocs, Addr);
}
ProcessedSymbols[i->first()] = i->second;
ExternalSymbolRelocations.erase(i);
}
// Restore the relocation entries that were consumed in the loop above:
//
// FIXME: Replace the following loop with:
// std::swap(ProcessedSymbols, ExternalSymbolRelocations)
// once StringMap has copy and move construction.
for (StringMap<RelocationList>::iterator I = ProcessedSymbols.begin(),
E = ProcessedSymbols.end();
I != E; ++I) {
ExternalSymbolRelocations[I->first()] = I->second;
}
}
//===----------------------------------------------------------------------===//