[LLVMdev] ORC and relocations
Eugene Rozenfeld
Eugene.Rozenfeld at microsoft.com
Wed Jul 22 19:26:33 PDT 2015
Hi Lang,
It turns out I also need an ability to tell the object linking layer not to apply any relocations. I need to skip this step below.
The only way I can see I can achieve that is by creating my own ObjectLinkingLayer that would duplicate almost all of orc::ObjectLinkingLayer.
I’d like to avoid that. An alternative it to pass a flag to orc::ObjectLinkingLayer constructor and orc::ObjectLinkingLayer::ConcreteLinkedObjectSet constructor
to indicate whether relocation resolution should be performed. Would you be ok with such a change?
Thanks,
Eugene
template <typename NotifyLoadedFtor = DoNothingOnNotifyLoaded>
class ObjectLinkingLayer : public ObjectLinkingLayerBase {
private:
template <typename MemoryManagerPtrT, typename SymbolResolverPtrT>
class ConcreteLinkedObjectSet : public LinkedObjectSet {
public:
ConcreteLinkedObjectSet(MemoryManagerPtrT MemMgr,
SymbolResolverPtrT Resolver)
: LinkedObjectSet(*MemMgr, *Resolver), MemMgr(std::move(MemMgr)),
Resolver(std::move(Resolver)) { }
void Finalize() override {
State = Finalizing;
RTDyld->resolveRelocations();
RTDyld->registerEHFrames();
MemMgr->finalizeMemory();
OwnedBuffers.clear();
State = Finalized;
}
From: Lang Hames [mailto:lhames at gmail.com]
Sent: Friday, July 3, 2015 6:36 PM
To: Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com>
Cc: llvmdev at cs.uiuc.edu
Subject: Re: ORC and relocations
Hi Eugene,
Sorry for the delayed reply. This looks good to me - I've applied it (along with some extra code to make it testable) in r241383.
Cheers,
Lang.
On Mon, Jun 29, 2015 at 7:31 PM, Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com<mailto:Eugene.Rozenfeld at microsoft.com>> wrote:
Hi Lang,
Yes, I can return a non-zero marker value. Are you ok with this version?
void RuntimeDyldImpl::resolveExternalSymbols() {
while (!ExternalSymbolRelocations.empty()) {
StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin();
StringRef Name = i->first();
if (Name.size() == 0) {
// This is an absolute symbol, use an address of zero.
DEBUG(dbgs() << "Resolving absolute relocations."
<< "\n");
RelocationList &Relocs = i->second;
resolveRelocationList(Relocs, 0);
} else {
uint64_t Addr = 0;
RTDyldSymbolTable::const_iterator Loc = GlobalSymbolTable.find(Name);
if (Loc == GlobalSymbolTable.end()) {
// This is an external symbol, try to get its address from the symbol
// resolver.
Addr = Resolver.findSymbol(Name.data()).getAddress();
// The call to getSymbolAddress may have caused additional modules to
// be loaded, which may have added new entries to the
// ExternalSymbolRelocations map. Consquently, we need to update our
// iterator. This is also why retrieval of the relocation list
// associated with this symbol is deferred until below this point.
// New entries may have been added to the relocation list.
i = ExternalSymbolRelocations.find(Name);
} else {
// We found the symbol in our global table. It was probably in a
// Module that we loaded previously.
const auto &SymInfo = Loc->second;
Addr = getSectionLoadAddress(SymInfo.getSectionID()) +
SymInfo.getOffset();
}
// FIXME: Implement error handling that doesn't kill the host program!
if (!Addr) {
report_fatal_error("Program used external function '" + Name +
"' which could not be resolved!");
}
// If Resolver returned UINT64_MAX, the client wants to handle this symbol
// manually and we shouldn't resolve its relocations.
if (Addr != UINT64_MAX) {
DEBUG(dbgs() << "Resolving relocations Name: " << Name << "\t"
<< format("0x%lx", Addr) << "\n");
// This list may have been updated when we called getSymbolAddress, so
// don't change this code to get the list earlier.
RelocationList &Relocs = i->second;
resolveRelocationList(Relocs, Addr);
}
}
ExternalSymbolRelocations.erase(i);
}
}
Thanks,
Eugene
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150723/d007fb70/attachment.html>
More information about the llvm-dev
mailing list