[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