2011-04-22 03:07:06 +00:00
|
|
|
//===-- MCJIT.cpp - MC-based Just-in-Time Compiler ------------------------===//
|
2010-11-17 16:06:43 +00:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "MCJIT.h"
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2010-11-17 16:06:43 +00:00
|
|
|
#include "llvm/ExecutionEngine/GenericValue.h"
|
2012-11-06 18:51:59 +00:00
|
|
|
#include "llvm/ExecutionEngine/JITEventListener.h"
|
2012-10-02 21:18:39 +00:00
|
|
|
#include "llvm/ExecutionEngine/MCJIT.h"
|
2013-04-29 17:49:40 +00:00
|
|
|
#include "llvm/ExecutionEngine/SectionMemoryManager.h"
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/DataLayout.h"
|
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
2015-02-13 10:01:29 +00:00
|
|
|
#include "llvm/IR/LegacyPassManager.h"
|
2014-01-07 21:19:40 +00:00
|
|
|
#include "llvm/IR/Mangler.h"
|
2013-10-01 01:47:35 +00:00
|
|
|
#include "llvm/IR/Module.h"
|
2011-03-22 01:06:42 +00:00
|
|
|
#include "llvm/MC/MCAsmInfo.h"
|
2014-01-08 04:09:09 +00:00
|
|
|
#include "llvm/Object/Archive.h"
|
2014-11-26 16:54:40 +00:00
|
|
|
#include "llvm/Object/ObjectFile.h"
|
2010-11-29 18:16:10 +00:00
|
|
|
#include "llvm/Support/DynamicLibrary.h"
|
2012-12-03 16:50:05 +00:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2011-03-22 01:06:42 +00:00
|
|
|
#include "llvm/Support/MemoryBuffer.h"
|
2014-06-20 21:07:14 +00:00
|
|
|
#include "llvm/Support/MutexGuard.h"
|
2010-11-17 16:06:43 +00:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2014-11-26 16:54:40 +00:00
|
|
|
void ObjectCache::anchor() {}
|
|
|
|
|
2010-11-17 16:06:43 +00:00
|
|
|
namespace {
|
|
|
|
|
|
|
|
static struct RegisterJIT {
|
|
|
|
RegisterJIT() { MCJIT::Register(); }
|
|
|
|
} JITRegistrator;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
extern "C" void LLVMLinkInMCJIT() {
|
|
|
|
}
|
|
|
|
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
ExecutionEngine*
|
|
|
|
MCJIT::createJIT(std::unique_ptr<Module> M,
|
|
|
|
std::string *ErrorStr,
|
|
|
|
std::shared_ptr<MCJITMemoryManager> MemMgr,
|
|
|
|
std::shared_ptr<RuntimeDyld::SymbolResolver> Resolver,
|
|
|
|
std::unique_ptr<TargetMachine> TM) {
|
2010-11-17 16:06:43 +00:00
|
|
|
// Try to register the program as a source of symbols to resolve against.
|
|
|
|
//
|
|
|
|
// FIXME: Don't do this here.
|
2014-04-24 06:44:33 +00:00
|
|
|
sys::DynamicLibrary::LoadLibraryPermanently(nullptr, nullptr);
|
2010-11-17 16:06:43 +00:00
|
|
|
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
if (!MemMgr || !Resolver) {
|
|
|
|
auto RTDyldMM = std::make_shared<SectionMemoryManager>();
|
|
|
|
if (!MemMgr)
|
|
|
|
MemMgr = RTDyldMM;
|
|
|
|
if (!Resolver)
|
|
|
|
Resolver = RTDyldMM;
|
|
|
|
}
|
2014-12-03 00:51:19 +00:00
|
|
|
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
return new MCJIT(std::move(M), std::move(TM), std::move(MemMgr),
|
|
|
|
std::move(Resolver));
|
2010-11-17 16:06:43 +00:00
|
|
|
}
|
|
|
|
|
2014-09-02 22:41:07 +00:00
|
|
|
MCJIT::MCJIT(std::unique_ptr<Module> M, std::unique_ptr<TargetMachine> tm,
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
std::shared_ptr<MCJITMemoryManager> MemMgr,
|
|
|
|
std::shared_ptr<RuntimeDyld::SymbolResolver> Resolver)
|
2014-09-02 22:41:07 +00:00
|
|
|
: ExecutionEngine(std::move(M)), TM(std::move(tm)), Ctx(nullptr),
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
MemMgr(std::move(MemMgr)), Resolver(*this, std::move(Resolver)),
|
|
|
|
Dyld(*this->MemMgr, this->Resolver), ObjCache(nullptr) {
|
2013-10-24 00:19:14 +00:00
|
|
|
// FIXME: We are managing our modules, so we do not want the base class
|
|
|
|
// ExecutionEngine to manage them as well. To avoid double destruction
|
|
|
|
// of the first (and only) module added in ExecutionEngine constructor
|
|
|
|
// we remove it from EE and will destruct it ourselves.
|
|
|
|
//
|
|
|
|
// It may make sense to move our module manager (based on SmallStPtr) back
|
|
|
|
// into EE if the JIT and Interpreter can live with it.
|
|
|
|
// If so, additional functions: addModule, removeModule, FindFunctionNamed,
|
|
|
|
// runStaticConstructorsDestructors could be moved back to EE as well.
|
|
|
|
//
|
2014-08-19 04:04:25 +00:00
|
|
|
std::unique_ptr<Module> First = std::move(Modules[0]);
|
2013-10-24 00:19:14 +00:00
|
|
|
Modules.clear();
|
2014-08-19 04:04:25 +00:00
|
|
|
|
|
|
|
OwnedModules.addModule(std::move(First));
|
2015-01-26 19:03:15 +00:00
|
|
|
setDataLayout(TM->getDataLayout());
|
2014-11-26 16:54:40 +00:00
|
|
|
RegisterJITEventListener(JITEventListener::createGDBRegistrationListener());
|
2014-08-19 04:04:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
MCJIT::~MCJIT() {
|
|
|
|
MutexGuard locked(lock);
|
|
|
|
|
2013-10-16 00:14:21 +00:00
|
|
|
Dyld.deregisterEHFrames();
|
2013-10-24 09:52:56 +00:00
|
|
|
|
2014-09-03 19:48:09 +00:00
|
|
|
for (auto &Obj : LoadedObjects)
|
|
|
|
if (Obj)
|
2013-10-24 09:52:56 +00:00
|
|
|
NotifyFreeingObject(*Obj);
|
2014-01-08 04:09:09 +00:00
|
|
|
|
|
|
|
Archives.clear();
|
2012-08-07 18:33:00 +00:00
|
|
|
}
|
|
|
|
|
2014-08-19 04:04:25 +00:00
|
|
|
void MCJIT::addModule(std::unique_ptr<Module> M) {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2014-08-19 04:04:25 +00:00
|
|
|
OwnedModules.addModule(std::move(M));
|
2013-10-24 00:19:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool MCJIT::removeModule(Module *M) {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2013-10-24 00:19:14 +00:00
|
|
|
return OwnedModules.removeModule(M);
|
2013-10-01 01:47:35 +00:00
|
|
|
}
|
|
|
|
|
2014-04-29 21:52:46 +00:00
|
|
|
void MCJIT::addObjectFile(std::unique_ptr<object::ObjectFile> Obj) {
|
2014-11-26 16:54:40 +00:00
|
|
|
std::unique_ptr<RuntimeDyld::LoadedObjectInfo> L = Dyld.loadObject(*Obj);
|
|
|
|
if (Dyld.hasError())
|
2014-01-08 04:09:09 +00:00
|
|
|
report_fatal_error(Dyld.getErrorString());
|
|
|
|
|
2014-11-26 16:54:40 +00:00
|
|
|
NotifyObjectEmitted(*Obj, *L);
|
2014-09-04 18:37:31 +00:00
|
|
|
|
2014-11-26 16:54:40 +00:00
|
|
|
LoadedObjects.push_back(std::move(Obj));
|
2014-01-08 04:09:09 +00:00
|
|
|
}
|
|
|
|
|
2014-08-26 21:04:04 +00:00
|
|
|
void MCJIT::addObjectFile(object::OwningBinary<object::ObjectFile> Obj) {
|
2014-10-31 21:37:49 +00:00
|
|
|
std::unique_ptr<object::ObjectFile> ObjFile;
|
|
|
|
std::unique_ptr<MemoryBuffer> MemBuf;
|
|
|
|
std::tie(ObjFile, MemBuf) = Obj.takeBinary();
|
|
|
|
addObjectFile(std::move(ObjFile));
|
|
|
|
Buffers.push_back(std::move(MemBuf));
|
2014-08-26 21:04:04 +00:00
|
|
|
}
|
|
|
|
|
2014-08-19 18:44:46 +00:00
|
|
|
void MCJIT::addArchive(object::OwningBinary<object::Archive> A) {
|
2014-08-01 18:09:32 +00:00
|
|
|
Archives.push_back(std::move(A));
|
2014-01-08 04:09:09 +00:00
|
|
|
}
|
|
|
|
|
2013-04-25 21:02:36 +00:00
|
|
|
void MCJIT::setObjectCache(ObjectCache* NewCache) {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2013-04-25 21:02:36 +00:00
|
|
|
ObjCache = NewCache;
|
|
|
|
}
|
|
|
|
|
2014-11-26 16:54:40 +00:00
|
|
|
std::unique_ptr<MemoryBuffer> MCJIT::emitObject(Module *M) {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2013-10-21 17:42:06 +00:00
|
|
|
|
2013-10-24 00:19:14 +00:00
|
|
|
// This must be a module which has already been added but not loaded to this
|
|
|
|
// MCJIT instance, since these conditions are tested by our caller,
|
|
|
|
// generateCodeForModule.
|
2012-08-07 18:33:00 +00:00
|
|
|
|
2015-02-13 10:01:29 +00:00
|
|
|
legacy::PassManager PM;
|
2012-08-07 18:33:00 +00:00
|
|
|
|
2015-03-04 18:43:29 +00:00
|
|
|
M->setDataLayout(*TM->getDataLayout());
|
2011-03-18 22:48:41 +00:00
|
|
|
|
2012-10-02 21:18:39 +00:00
|
|
|
// The RuntimeDyld will take ownership of this shortly
|
2014-11-26 16:54:40 +00:00
|
|
|
SmallVector<char, 4096> ObjBufferSV;
|
|
|
|
raw_svector_ostream ObjStream(ObjBufferSV);
|
2012-10-02 21:18:39 +00:00
|
|
|
|
2011-03-18 22:48:41 +00:00
|
|
|
// Turn the machine code intermediate representation into bytes in memory
|
|
|
|
// that may be executed.
|
2014-11-26 16:54:40 +00:00
|
|
|
if (TM->addPassesToEmitMC(PM, Ctx, ObjStream, !getVerifyModules()))
|
2011-03-18 22:48:41 +00:00
|
|
|
report_fatal_error("Target does not support MC emission!");
|
|
|
|
|
|
|
|
// Initialize passes.
|
2013-10-01 01:47:35 +00:00
|
|
|
PM.run(*M);
|
2012-10-02 21:18:39 +00:00
|
|
|
// Flush the output buffer to get the generated code into memory
|
2014-11-26 16:54:40 +00:00
|
|
|
ObjStream.flush();
|
|
|
|
|
|
|
|
std::unique_ptr<MemoryBuffer> CompiledObjBuffer(
|
|
|
|
new ObjectMemoryBuffer(std::move(ObjBufferSV)));
|
2013-04-25 21:02:36 +00:00
|
|
|
|
|
|
|
// If we have an object cache, tell it about the new object.
|
|
|
|
// Note that we're using the compiled image, not the loaded image (as below).
|
|
|
|
if (ObjCache) {
|
|
|
|
// MemoryBuffer is a thin wrapper around the actual memory, so it's OK
|
|
|
|
// to create a temporary object here and delete it after the call.
|
2014-11-26 16:54:40 +00:00
|
|
|
MemoryBufferRef MB = CompiledObjBuffer->getMemBufferRef();
|
2014-08-19 18:44:46 +00:00
|
|
|
ObjCache->notifyObjectCompiled(M, MB);
|
2013-04-25 21:02:36 +00:00
|
|
|
}
|
|
|
|
|
2014-11-26 16:54:40 +00:00
|
|
|
return CompiledObjBuffer;
|
2013-04-25 21:02:36 +00:00
|
|
|
}
|
|
|
|
|
2013-10-01 01:47:35 +00:00
|
|
|
void MCJIT::generateCodeForModule(Module *M) {
|
2013-10-21 17:42:06 +00:00
|
|
|
// Get a thread lock to make sure we aren't trying to load multiple times
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2013-10-21 17:42:06 +00:00
|
|
|
|
2013-10-01 01:47:35 +00:00
|
|
|
// This must be a module which has already been added to this MCJIT instance.
|
2013-10-24 00:19:14 +00:00
|
|
|
assert(OwnedModules.ownsModule(M) &&
|
|
|
|
"MCJIT::generateCodeForModule: Unknown module.");
|
2013-04-25 21:02:36 +00:00
|
|
|
|
|
|
|
// Re-compilation is not supported
|
2013-10-24 00:19:14 +00:00
|
|
|
if (OwnedModules.hasModuleBeenLoaded(M))
|
2013-04-25 21:02:36 +00:00
|
|
|
return;
|
|
|
|
|
2014-11-26 16:54:40 +00:00
|
|
|
std::unique_ptr<MemoryBuffer> ObjectToLoad;
|
2013-04-25 21:02:36 +00:00
|
|
|
// Try to load the pre-compiled object from cache if possible
|
2014-11-26 16:54:40 +00:00
|
|
|
if (ObjCache)
|
|
|
|
ObjectToLoad = ObjCache->getObject(M);
|
2013-04-25 21:02:36 +00:00
|
|
|
|
|
|
|
// If the cache did not contain a suitable object, compile the object
|
|
|
|
if (!ObjectToLoad) {
|
2014-09-03 19:57:35 +00:00
|
|
|
ObjectToLoad = emitObject(M);
|
|
|
|
assert(ObjectToLoad && "Compilation did not produce an object.");
|
2013-04-25 21:02:36 +00:00
|
|
|
}
|
2011-03-22 01:06:42 +00:00
|
|
|
|
|
|
|
// Load the object into the dynamic linker.
|
2014-01-08 04:09:09 +00:00
|
|
|
// MCJIT now owns the ObjectImage pointer (via its LoadedObjects list).
|
2014-11-26 16:54:40 +00:00
|
|
|
ErrorOr<std::unique_ptr<object::ObjectFile>> LoadedObject =
|
|
|
|
object::ObjectFile::createObjectFile(ObjectToLoad->getMemBufferRef());
|
|
|
|
std::unique_ptr<RuntimeDyld::LoadedObjectInfo> L =
|
|
|
|
Dyld.loadObject(*LoadedObject.get());
|
2012-10-02 21:18:39 +00:00
|
|
|
|
2014-11-26 16:54:40 +00:00
|
|
|
if (Dyld.hasError())
|
|
|
|
report_fatal_error(Dyld.getErrorString());
|
2014-11-26 15:27:39 +00:00
|
|
|
|
2014-11-26 16:54:40 +00:00
|
|
|
NotifyObjectEmitted(*LoadedObject.get(), *L);
|
2012-11-06 18:51:59 +00:00
|
|
|
|
2014-11-26 16:54:40 +00:00
|
|
|
Buffers.push_back(std::move(ObjectToLoad));
|
|
|
|
LoadedObjects.push_back(std::move(*LoadedObject));
|
2014-09-03 19:48:09 +00:00
|
|
|
|
2013-10-24 00:19:14 +00:00
|
|
|
OwnedModules.markModuleAsLoaded(M);
|
2013-10-01 01:47:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCJIT::finalizeLoadedModules() {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2013-10-21 17:42:06 +00:00
|
|
|
|
2013-10-01 01:47:35 +00:00
|
|
|
// Resolve any outstanding relocations.
|
|
|
|
Dyld.resolveRelocations();
|
|
|
|
|
2013-10-24 00:19:14 +00:00
|
|
|
OwnedModules.markAllLoadedModulesAsFinalized();
|
2013-10-01 01:47:35 +00:00
|
|
|
|
2013-10-24 00:19:14 +00:00
|
|
|
// Register EH frame data for any module we own which has been loaded
|
2013-10-11 21:25:48 +00:00
|
|
|
Dyld.registerEHFrames();
|
|
|
|
|
2013-10-01 01:47:35 +00:00
|
|
|
// Set page permissions.
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
MemMgr->finalizeMemory();
|
2010-11-17 16:06:43 +00:00
|
|
|
}
|
|
|
|
|
2013-10-01 01:47:35 +00:00
|
|
|
// FIXME: Rename this.
|
2012-11-05 20:57:16 +00:00
|
|
|
void MCJIT::finalizeObject() {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2013-10-21 17:42:06 +00:00
|
|
|
|
2014-09-05 23:38:35 +00:00
|
|
|
// Generate code for module is going to move objects out of the 'added' list,
|
|
|
|
// so we need to copy that out before using it:
|
|
|
|
SmallVector<Module*, 16> ModsToAdd;
|
|
|
|
for (auto M : OwnedModules.added())
|
|
|
|
ModsToAdd.push_back(M);
|
|
|
|
|
|
|
|
for (auto M : ModsToAdd)
|
2013-10-24 00:19:14 +00:00
|
|
|
generateCodeForModule(M);
|
2012-11-05 20:57:16 +00:00
|
|
|
|
2013-10-24 00:19:14 +00:00
|
|
|
finalizeLoadedModules();
|
2013-10-01 01:47:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCJIT::finalizeModule(Module *M) {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2013-10-21 17:42:06 +00:00
|
|
|
|
2013-10-01 01:47:35 +00:00
|
|
|
// This must be a module which has already been added to this MCJIT instance.
|
2013-10-24 00:19:14 +00:00
|
|
|
assert(OwnedModules.ownsModule(M) && "MCJIT::finalizeModule: Unknown module.");
|
2013-10-01 01:47:35 +00:00
|
|
|
|
|
|
|
// If the module hasn't been compiled, just do that.
|
2013-10-24 00:19:14 +00:00
|
|
|
if (!OwnedModules.hasModuleBeenLoaded(M))
|
2013-10-01 01:47:35 +00:00
|
|
|
generateCodeForModule(M);
|
|
|
|
|
2013-10-24 00:19:14 +00:00
|
|
|
finalizeLoadedModules();
|
2012-11-05 20:57:16 +00:00
|
|
|
}
|
|
|
|
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
RuntimeDyld::SymbolInfo MCJIT::findExistingSymbol(const std::string &Name) {
|
2015-01-26 19:03:15 +00:00
|
|
|
Mangler Mang(TM->getDataLayout());
|
2013-11-28 08:59:52 +00:00
|
|
|
SmallString<128> FullName;
|
|
|
|
Mang.getNameWithPrefix(FullName, Name);
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
return Dyld.getSymbol(FullName);
|
2013-10-01 01:47:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Module *MCJIT::findModuleForSymbol(const std::string &Name,
|
|
|
|
bool CheckFunctionsOnly) {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2013-10-21 17:42:06 +00:00
|
|
|
|
2013-10-01 01:47:35 +00:00
|
|
|
// If it hasn't already been generated, see if it's in one of our modules.
|
2013-10-24 00:19:14 +00:00
|
|
|
for (ModulePtrSet::iterator I = OwnedModules.begin_added(),
|
|
|
|
E = OwnedModules.end_added();
|
|
|
|
I != E; ++I) {
|
|
|
|
Module *M = *I;
|
2013-10-01 01:47:35 +00:00
|
|
|
Function *F = M->getFunction(Name);
|
2013-11-15 22:10:21 +00:00
|
|
|
if (F && !F->isDeclaration())
|
2013-10-01 01:47:35 +00:00
|
|
|
return M;
|
|
|
|
if (!CheckFunctionsOnly) {
|
|
|
|
GlobalVariable *G = M->getGlobalVariable(Name);
|
2013-11-15 22:10:21 +00:00
|
|
|
if (G && !G->isDeclaration())
|
2013-10-01 01:47:35 +00:00
|
|
|
return M;
|
|
|
|
// FIXME: Do we need to worry about global aliases?
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// We didn't find the symbol in any of our modules.
|
2014-04-24 06:44:33 +00:00
|
|
|
return nullptr;
|
2013-10-01 01:47:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t MCJIT::getSymbolAddress(const std::string &Name,
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
bool CheckFunctionsOnly) {
|
|
|
|
return findSymbol(Name, CheckFunctionsOnly).getAddress();
|
|
|
|
}
|
|
|
|
|
|
|
|
RuntimeDyld::SymbolInfo MCJIT::findSymbol(const std::string &Name,
|
|
|
|
bool CheckFunctionsOnly) {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2013-10-21 17:42:06 +00:00
|
|
|
|
2013-10-01 01:47:35 +00:00
|
|
|
// First, check to see if we already have this symbol.
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
if (auto Sym = findExistingSymbol(Name))
|
|
|
|
return Sym;
|
2013-10-01 01:47:35 +00:00
|
|
|
|
2014-08-19 18:44:46 +00:00
|
|
|
for (object::OwningBinary<object::Archive> &OB : Archives) {
|
2014-10-31 21:37:49 +00:00
|
|
|
object::Archive *A = OB.getBinary();
|
2014-01-08 04:09:09 +00:00
|
|
|
// Look for our symbols in each Archive
|
|
|
|
object::Archive::child_iterator ChildIt = A->findSym(Name);
|
2014-01-21 16:09:45 +00:00
|
|
|
if (ChildIt != A->child_end()) {
|
2014-01-08 04:09:09 +00:00
|
|
|
// FIXME: Support nested archives?
|
2014-06-16 16:08:36 +00:00
|
|
|
ErrorOr<std::unique_ptr<object::Binary>> ChildBinOrErr =
|
|
|
|
ChildIt->getAsBinary();
|
|
|
|
if (ChildBinOrErr.getError())
|
|
|
|
continue;
|
2014-08-01 14:31:55 +00:00
|
|
|
std::unique_ptr<object::Binary> &ChildBin = ChildBinOrErr.get();
|
2014-06-16 16:08:36 +00:00
|
|
|
if (ChildBin->isObject()) {
|
2014-04-29 21:52:46 +00:00
|
|
|
std::unique_ptr<object::ObjectFile> OF(
|
|
|
|
static_cast<object::ObjectFile *>(ChildBin.release()));
|
2014-01-08 04:09:09 +00:00
|
|
|
// This causes the object file to be loaded.
|
2014-04-29 21:52:46 +00:00
|
|
|
addObjectFile(std::move(OF));
|
2014-01-08 04:09:09 +00:00
|
|
|
// The address should be here now.
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
if (auto Sym = findExistingSymbol(Name))
|
|
|
|
return Sym;
|
2014-01-08 04:09:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-01 01:47:35 +00:00
|
|
|
// If it hasn't already been generated, see if it's in one of our modules.
|
|
|
|
Module *M = findModuleForSymbol(Name, CheckFunctionsOnly);
|
2014-08-14 02:38:20 +00:00
|
|
|
if (M) {
|
|
|
|
generateCodeForModule(M);
|
|
|
|
|
|
|
|
// Check the RuntimeDyld table again, it should be there now.
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
return findExistingSymbol(Name);
|
2014-08-14 02:38:20 +00:00
|
|
|
}
|
2013-10-01 01:47:35 +00:00
|
|
|
|
2014-08-14 02:38:20 +00:00
|
|
|
// If a LazyFunctionCreator is installed, use it to get/create the function.
|
|
|
|
// FIXME: Should we instead have a LazySymbolCreator callback?
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
if (LazyFunctionCreator) {
|
|
|
|
auto Addr = static_cast<uint64_t>(
|
|
|
|
reinterpret_cast<uintptr_t>(LazyFunctionCreator(Name)));
|
|
|
|
return RuntimeDyld::SymbolInfo(Addr, JITSymbolFlags::Exported);
|
|
|
|
}
|
2013-10-01 01:47:35 +00:00
|
|
|
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
return nullptr;
|
2013-10-01 01:47:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t MCJIT::getGlobalValueAddress(const std::string &Name) {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2013-10-01 01:47:35 +00:00
|
|
|
uint64_t Result = getSymbolAddress(Name, false);
|
|
|
|
if (Result != 0)
|
|
|
|
finalizeLoadedModules();
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t MCJIT::getFunctionAddress(const std::string &Name) {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2013-10-01 01:47:35 +00:00
|
|
|
uint64_t Result = getSymbolAddress(Name, true);
|
|
|
|
if (Result != 0)
|
|
|
|
finalizeLoadedModules();
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Deprecated. Use getFunctionAddress instead.
|
|
|
|
void *MCJIT::getPointerToFunction(Function *F) {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2012-08-07 18:33:00 +00:00
|
|
|
|
2015-01-26 19:03:15 +00:00
|
|
|
Mangler Mang(TM->getDataLayout());
|
[MCJIT] Make RTDyldMemoryManager::getSymbolAddress's behaviour more consistent.
This patch modifies RTDyldMemoryManager::getSymbolAddress(Name)'s behavior to
make it consistent with how clients are using it: Name should be mangled, and
getSymbolAddress should demangle it on the caller's behalf before looking the
name up in the process. This patch also fixes the one client
(MCJIT::getPointerToFunction) that had been passing unmangled names (by having
it pass mangled names instead).
Background:
RTDyldMemoryManager::getSymbolAddress(Name) has always used a re-try mechanism
when looking up symbol names in the current process. Prior to this patch
getSymbolAddress first tried to look up 'Name' exactly as the user passed it in
and then, if that failed, tried to demangle 'Name' and re-try the look up. The
implication of this behavior is that getSymbolAddress expected to be called with
unmangled names, and that handling mangled names was a fallback for convenience.
This is inconsistent with how clients (particularly the RuntimeDyldImpl
subclasses, but also MCJIT) usually use this API. Most clients pass in mangled
names, and succeed only because of the fallback case. For clients passing in
mangled names, getSymbolAddress's old behavior was actually dangerous, as it
could cause unmangled names in the process to shadow mangled names being looked
up.
For example, consider:
foo.c:
int _x = 7;
int x() { return _x; }
foo.o:
000000000000000c D __x
0000000000000000 T _x
If foo.c becomes part of the process (E.g. via dlopen("libfoo.dylib")) it will
add symbols 'x' (the function) and '_x' (the variable) to the process. However
jit clients looking for the function 'x' will be using the mangled function name
'_x' (note how function 'x' appears in foo.o). When getSymbolAddress goes
looking for '_x' it will find the variable instead, and return its address and
in place of the function, leading to JIT'd code calling the variable and
crashing (if we're lucky).
By requiring that getSymbolAddress be called with mangled names, and demangling
only when we're about to do a lookup in the process, the new behavior
implemented in this patch should eliminate any chance of names being shadowed
during lookup.
There's no good way to test this at the moment: This issue only arrises when
looking up process symbols (not JIT'd symbols). Any test case would have to
generate a platform-appropriate dylib to pass to llvm-rtdyld, and I'm not
aware of any in-tree tool for doing this in a portable way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218187 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-20 17:44:56 +00:00
|
|
|
SmallString<128> Name;
|
|
|
|
TM->getNameWithPrefix(Name, F, Mang);
|
|
|
|
|
2011-03-22 18:05:27 +00:00
|
|
|
if (F->isDeclaration() || F->hasAvailableExternallyLinkage()) {
|
|
|
|
bool AbortOnFailure = !F->hasExternalWeakLinkage();
|
[MCJIT] Make RTDyldMemoryManager::getSymbolAddress's behaviour more consistent.
This patch modifies RTDyldMemoryManager::getSymbolAddress(Name)'s behavior to
make it consistent with how clients are using it: Name should be mangled, and
getSymbolAddress should demangle it on the caller's behalf before looking the
name up in the process. This patch also fixes the one client
(MCJIT::getPointerToFunction) that had been passing unmangled names (by having
it pass mangled names instead).
Background:
RTDyldMemoryManager::getSymbolAddress(Name) has always used a re-try mechanism
when looking up symbol names in the current process. Prior to this patch
getSymbolAddress first tried to look up 'Name' exactly as the user passed it in
and then, if that failed, tried to demangle 'Name' and re-try the look up. The
implication of this behavior is that getSymbolAddress expected to be called with
unmangled names, and that handling mangled names was a fallback for convenience.
This is inconsistent with how clients (particularly the RuntimeDyldImpl
subclasses, but also MCJIT) usually use this API. Most clients pass in mangled
names, and succeed only because of the fallback case. For clients passing in
mangled names, getSymbolAddress's old behavior was actually dangerous, as it
could cause unmangled names in the process to shadow mangled names being looked
up.
For example, consider:
foo.c:
int _x = 7;
int x() { return _x; }
foo.o:
000000000000000c D __x
0000000000000000 T _x
If foo.c becomes part of the process (E.g. via dlopen("libfoo.dylib")) it will
add symbols 'x' (the function) and '_x' (the variable) to the process. However
jit clients looking for the function 'x' will be using the mangled function name
'_x' (note how function 'x' appears in foo.o). When getSymbolAddress goes
looking for '_x' it will find the variable instead, and return its address and
in place of the function, leading to JIT'd code calling the variable and
crashing (if we're lucky).
By requiring that getSymbolAddress be called with mangled names, and demangling
only when we're about to do a lookup in the process, the new behavior
implemented in this patch should eliminate any chance of names being shadowed
during lookup.
There's no good way to test this at the moment: This issue only arrises when
looking up process symbols (not JIT'd symbols). Any test case would have to
generate a platform-appropriate dylib to pass to llvm-rtdyld, and I'm not
aware of any in-tree tool for doing this in a portable way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218187 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-20 17:44:56 +00:00
|
|
|
void *Addr = getPointerToNamedFunction(Name, AbortOnFailure);
|
2014-10-22 23:18:42 +00:00
|
|
|
updateGlobalMapping(F, Addr);
|
2011-03-22 18:05:27 +00:00
|
|
|
return Addr;
|
|
|
|
}
|
|
|
|
|
2013-10-01 01:47:35 +00:00
|
|
|
Module *M = F->getParent();
|
2013-10-24 00:19:14 +00:00
|
|
|
bool HasBeenAddedButNotLoaded = OwnedModules.hasModuleBeenAddedButNotLoaded(M);
|
2013-10-01 01:47:35 +00:00
|
|
|
|
|
|
|
// Make sure the relevant module has been compiled and loaded.
|
2013-10-24 00:19:14 +00:00
|
|
|
if (HasBeenAddedButNotLoaded)
|
2013-10-01 01:47:35 +00:00
|
|
|
generateCodeForModule(M);
|
[MCJIT] Make RTDyldMemoryManager::getSymbolAddress's behaviour more consistent.
This patch modifies RTDyldMemoryManager::getSymbolAddress(Name)'s behavior to
make it consistent with how clients are using it: Name should be mangled, and
getSymbolAddress should demangle it on the caller's behalf before looking the
name up in the process. This patch also fixes the one client
(MCJIT::getPointerToFunction) that had been passing unmangled names (by having
it pass mangled names instead).
Background:
RTDyldMemoryManager::getSymbolAddress(Name) has always used a re-try mechanism
when looking up symbol names in the current process. Prior to this patch
getSymbolAddress first tried to look up 'Name' exactly as the user passed it in
and then, if that failed, tried to demangle 'Name' and re-try the look up. The
implication of this behavior is that getSymbolAddress expected to be called with
unmangled names, and that handling mangled names was a fallback for convenience.
This is inconsistent with how clients (particularly the RuntimeDyldImpl
subclasses, but also MCJIT) usually use this API. Most clients pass in mangled
names, and succeed only because of the fallback case. For clients passing in
mangled names, getSymbolAddress's old behavior was actually dangerous, as it
could cause unmangled names in the process to shadow mangled names being looked
up.
For example, consider:
foo.c:
int _x = 7;
int x() { return _x; }
foo.o:
000000000000000c D __x
0000000000000000 T _x
If foo.c becomes part of the process (E.g. via dlopen("libfoo.dylib")) it will
add symbols 'x' (the function) and '_x' (the variable) to the process. However
jit clients looking for the function 'x' will be using the mangled function name
'_x' (note how function 'x' appears in foo.o). When getSymbolAddress goes
looking for '_x' it will find the variable instead, and return its address and
in place of the function, leading to JIT'd code calling the variable and
crashing (if we're lucky).
By requiring that getSymbolAddress be called with mangled names, and demangling
only when we're about to do a lookup in the process, the new behavior
implemented in this patch should eliminate any chance of names being shadowed
during lookup.
There's no good way to test this at the moment: This issue only arrises when
looking up process symbols (not JIT'd symbols). Any test case would have to
generate a platform-appropriate dylib to pass to llvm-rtdyld, and I'm not
aware of any in-tree tool for doing this in a portable way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218187 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-20 17:44:56 +00:00
|
|
|
else if (!OwnedModules.hasModuleBeenLoaded(M)) {
|
2013-10-24 00:19:14 +00:00
|
|
|
// If this function doesn't belong to one of our modules, we're done.
|
[MCJIT] Make RTDyldMemoryManager::getSymbolAddress's behaviour more consistent.
This patch modifies RTDyldMemoryManager::getSymbolAddress(Name)'s behavior to
make it consistent with how clients are using it: Name should be mangled, and
getSymbolAddress should demangle it on the caller's behalf before looking the
name up in the process. This patch also fixes the one client
(MCJIT::getPointerToFunction) that had been passing unmangled names (by having
it pass mangled names instead).
Background:
RTDyldMemoryManager::getSymbolAddress(Name) has always used a re-try mechanism
when looking up symbol names in the current process. Prior to this patch
getSymbolAddress first tried to look up 'Name' exactly as the user passed it in
and then, if that failed, tried to demangle 'Name' and re-try the look up. The
implication of this behavior is that getSymbolAddress expected to be called with
unmangled names, and that handling mangled names was a fallback for convenience.
This is inconsistent with how clients (particularly the RuntimeDyldImpl
subclasses, but also MCJIT) usually use this API. Most clients pass in mangled
names, and succeed only because of the fallback case. For clients passing in
mangled names, getSymbolAddress's old behavior was actually dangerous, as it
could cause unmangled names in the process to shadow mangled names being looked
up.
For example, consider:
foo.c:
int _x = 7;
int x() { return _x; }
foo.o:
000000000000000c D __x
0000000000000000 T _x
If foo.c becomes part of the process (E.g. via dlopen("libfoo.dylib")) it will
add symbols 'x' (the function) and '_x' (the variable) to the process. However
jit clients looking for the function 'x' will be using the mangled function name
'_x' (note how function 'x' appears in foo.o). When getSymbolAddress goes
looking for '_x' it will find the variable instead, and return its address and
in place of the function, leading to JIT'd code calling the variable and
crashing (if we're lucky).
By requiring that getSymbolAddress be called with mangled names, and demangling
only when we're about to do a lookup in the process, the new behavior
implemented in this patch should eliminate any chance of names being shadowed
during lookup.
There's no good way to test this at the moment: This issue only arrises when
looking up process symbols (not JIT'd symbols). Any test case would have to
generate a platform-appropriate dylib to pass to llvm-rtdyld, and I'm not
aware of any in-tree tool for doing this in a portable way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218187 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-20 17:44:56 +00:00
|
|
|
// FIXME: Asking for the pointer to a function that hasn't been registered,
|
|
|
|
// and isn't a declaration (which is handled above) should probably
|
|
|
|
// be an assertion.
|
2014-04-24 06:44:33 +00:00
|
|
|
return nullptr;
|
[MCJIT] Make RTDyldMemoryManager::getSymbolAddress's behaviour more consistent.
This patch modifies RTDyldMemoryManager::getSymbolAddress(Name)'s behavior to
make it consistent with how clients are using it: Name should be mangled, and
getSymbolAddress should demangle it on the caller's behalf before looking the
name up in the process. This patch also fixes the one client
(MCJIT::getPointerToFunction) that had been passing unmangled names (by having
it pass mangled names instead).
Background:
RTDyldMemoryManager::getSymbolAddress(Name) has always used a re-try mechanism
when looking up symbol names in the current process. Prior to this patch
getSymbolAddress first tried to look up 'Name' exactly as the user passed it in
and then, if that failed, tried to demangle 'Name' and re-try the look up. The
implication of this behavior is that getSymbolAddress expected to be called with
unmangled names, and that handling mangled names was a fallback for convenience.
This is inconsistent with how clients (particularly the RuntimeDyldImpl
subclasses, but also MCJIT) usually use this API. Most clients pass in mangled
names, and succeed only because of the fallback case. For clients passing in
mangled names, getSymbolAddress's old behavior was actually dangerous, as it
could cause unmangled names in the process to shadow mangled names being looked
up.
For example, consider:
foo.c:
int _x = 7;
int x() { return _x; }
foo.o:
000000000000000c D __x
0000000000000000 T _x
If foo.c becomes part of the process (E.g. via dlopen("libfoo.dylib")) it will
add symbols 'x' (the function) and '_x' (the variable) to the process. However
jit clients looking for the function 'x' will be using the mangled function name
'_x' (note how function 'x' appears in foo.o). When getSymbolAddress goes
looking for '_x' it will find the variable instead, and return its address and
in place of the function, leading to JIT'd code calling the variable and
crashing (if we're lucky).
By requiring that getSymbolAddress be called with mangled names, and demangling
only when we're about to do a lookup in the process, the new behavior
implemented in this patch should eliminate any chance of names being shadowed
during lookup.
There's no good way to test this at the moment: This issue only arrises when
looking up process symbols (not JIT'd symbols). Any test case would have to
generate a platform-appropriate dylib to pass to llvm-rtdyld, and I'm not
aware of any in-tree tool for doing this in a portable way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218187 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-20 17:44:56 +00:00
|
|
|
}
|
2013-10-01 01:47:35 +00:00
|
|
|
|
2012-08-07 18:33:00 +00:00
|
|
|
// FIXME: Should the Dyld be retaining module information? Probably not.
|
2012-09-05 16:50:40 +00:00
|
|
|
//
|
|
|
|
// This is the accessor for the target address, so make sure to check the
|
|
|
|
// load address of the symbol, not the local address.
|
2015-03-11 00:43:26 +00:00
|
|
|
return (void*)Dyld.getSymbol(Name).getAddress();
|
2010-11-17 16:06:43 +00:00
|
|
|
}
|
|
|
|
|
2013-10-24 00:19:14 +00:00
|
|
|
void MCJIT::runStaticConstructorsDestructorsInModulePtrSet(
|
|
|
|
bool isDtors, ModulePtrSet::iterator I, ModulePtrSet::iterator E) {
|
|
|
|
for (; I != E; ++I) {
|
2014-08-19 04:04:25 +00:00
|
|
|
ExecutionEngine::runStaticConstructorsDestructors(**I, isDtors);
|
2013-10-24 00:19:14 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void MCJIT::runStaticConstructorsDestructors(bool isDtors) {
|
|
|
|
// Execute global ctors/dtors for each module in the program.
|
|
|
|
runStaticConstructorsDestructorsInModulePtrSet(
|
|
|
|
isDtors, OwnedModules.begin_added(), OwnedModules.end_added());
|
|
|
|
runStaticConstructorsDestructorsInModulePtrSet(
|
|
|
|
isDtors, OwnedModules.begin_loaded(), OwnedModules.end_loaded());
|
|
|
|
runStaticConstructorsDestructorsInModulePtrSet(
|
|
|
|
isDtors, OwnedModules.begin_finalized(), OwnedModules.end_finalized());
|
|
|
|
}
|
|
|
|
|
|
|
|
Function *MCJIT::FindFunctionNamedInModulePtrSet(const char *FnName,
|
|
|
|
ModulePtrSet::iterator I,
|
|
|
|
ModulePtrSet::iterator E) {
|
|
|
|
for (; I != E; ++I) {
|
2015-01-27 19:29:00 +00:00
|
|
|
Function *F = (*I)->getFunction(FnName);
|
|
|
|
if (F && !F->isDeclaration())
|
2013-10-24 00:19:14 +00:00
|
|
|
return F;
|
|
|
|
}
|
2014-04-24 06:44:33 +00:00
|
|
|
return nullptr;
|
2013-10-24 00:19:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Function *MCJIT::FindFunctionNamed(const char *FnName) {
|
|
|
|
Function *F = FindFunctionNamedInModulePtrSet(
|
|
|
|
FnName, OwnedModules.begin_added(), OwnedModules.end_added());
|
|
|
|
if (!F)
|
|
|
|
F = FindFunctionNamedInModulePtrSet(FnName, OwnedModules.begin_loaded(),
|
|
|
|
OwnedModules.end_loaded());
|
|
|
|
if (!F)
|
|
|
|
F = FindFunctionNamedInModulePtrSet(FnName, OwnedModules.begin_finalized(),
|
|
|
|
OwnedModules.end_finalized());
|
|
|
|
return F;
|
|
|
|
}
|
|
|
|
|
2010-11-17 16:06:43 +00:00
|
|
|
GenericValue MCJIT::runFunction(Function *F,
|
|
|
|
const std::vector<GenericValue> &ArgValues) {
|
2011-03-22 18:05:27 +00:00
|
|
|
assert(F && "Function *F was null at entry to run()");
|
|
|
|
|
2011-03-18 22:48:41 +00:00
|
|
|
void *FPtr = getPointerToFunction(F);
|
2011-03-22 18:05:27 +00:00
|
|
|
assert(FPtr && "Pointer to fn's code was null after getPointerToFunction");
|
2011-07-18 04:54:35 +00:00
|
|
|
FunctionType *FTy = F->getFunctionType();
|
|
|
|
Type *RetTy = FTy->getReturnType();
|
2011-03-22 18:05:27 +00:00
|
|
|
|
|
|
|
assert((FTy->getNumParams() == ArgValues.size() ||
|
|
|
|
(FTy->isVarArg() && FTy->getNumParams() <= ArgValues.size())) &&
|
|
|
|
"Wrong number of arguments passed into function!");
|
|
|
|
assert(FTy->getNumParams() == ArgValues.size() &&
|
|
|
|
"This doesn't support passing arguments through varargs (yet)!");
|
|
|
|
|
|
|
|
// Handle some common cases first. These cases correspond to common `main'
|
|
|
|
// prototypes.
|
|
|
|
if (RetTy->isIntegerTy(32) || RetTy->isVoidTy()) {
|
|
|
|
switch (ArgValues.size()) {
|
|
|
|
case 3:
|
|
|
|
if (FTy->getParamType(0)->isIntegerTy(32) &&
|
|
|
|
FTy->getParamType(1)->isPointerTy() &&
|
|
|
|
FTy->getParamType(2)->isPointerTy()) {
|
|
|
|
int (*PF)(int, char **, const char **) =
|
|
|
|
(int(*)(int, char **, const char **))(intptr_t)FPtr;
|
|
|
|
|
|
|
|
// Call the function.
|
|
|
|
GenericValue rv;
|
|
|
|
rv.IntVal = APInt(32, PF(ArgValues[0].IntVal.getZExtValue(),
|
|
|
|
(char **)GVTOP(ArgValues[1]),
|
|
|
|
(const char **)GVTOP(ArgValues[2])));
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
if (FTy->getParamType(0)->isIntegerTy(32) &&
|
|
|
|
FTy->getParamType(1)->isPointerTy()) {
|
|
|
|
int (*PF)(int, char **) = (int(*)(int, char **))(intptr_t)FPtr;
|
|
|
|
|
|
|
|
// Call the function.
|
|
|
|
GenericValue rv;
|
|
|
|
rv.IntVal = APInt(32, PF(ArgValues[0].IntVal.getZExtValue(),
|
|
|
|
(char **)GVTOP(ArgValues[1])));
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
if (FTy->getNumParams() == 1 &&
|
|
|
|
FTy->getParamType(0)->isIntegerTy(32)) {
|
|
|
|
GenericValue rv;
|
|
|
|
int (*PF)(int) = (int(*)(int))(intptr_t)FPtr;
|
|
|
|
rv.IntVal = APInt(32, PF(ArgValues[0].IntVal.getZExtValue()));
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Handle cases where no arguments are passed first.
|
|
|
|
if (ArgValues.empty()) {
|
|
|
|
GenericValue rv;
|
|
|
|
switch (RetTy->getTypeID()) {
|
|
|
|
default: llvm_unreachable("Unknown return type for function call!");
|
|
|
|
case Type::IntegerTyID: {
|
|
|
|
unsigned BitWidth = cast<IntegerType>(RetTy)->getBitWidth();
|
|
|
|
if (BitWidth == 1)
|
|
|
|
rv.IntVal = APInt(BitWidth, ((bool(*)())(intptr_t)FPtr)());
|
|
|
|
else if (BitWidth <= 8)
|
|
|
|
rv.IntVal = APInt(BitWidth, ((char(*)())(intptr_t)FPtr)());
|
|
|
|
else if (BitWidth <= 16)
|
|
|
|
rv.IntVal = APInt(BitWidth, ((short(*)())(intptr_t)FPtr)());
|
|
|
|
else if (BitWidth <= 32)
|
|
|
|
rv.IntVal = APInt(BitWidth, ((int(*)())(intptr_t)FPtr)());
|
|
|
|
else if (BitWidth <= 64)
|
|
|
|
rv.IntVal = APInt(BitWidth, ((int64_t(*)())(intptr_t)FPtr)());
|
|
|
|
else
|
|
|
|
llvm_unreachable("Integer types > 64 bits not supported");
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
case Type::VoidTyID:
|
|
|
|
rv.IntVal = APInt(32, ((int(*)())(intptr_t)FPtr)());
|
|
|
|
return rv;
|
|
|
|
case Type::FloatTyID:
|
|
|
|
rv.FloatVal = ((float(*)())(intptr_t)FPtr)();
|
|
|
|
return rv;
|
|
|
|
case Type::DoubleTyID:
|
|
|
|
rv.DoubleVal = ((double(*)())(intptr_t)FPtr)();
|
|
|
|
return rv;
|
|
|
|
case Type::X86_FP80TyID:
|
|
|
|
case Type::FP128TyID:
|
|
|
|
case Type::PPC_FP128TyID:
|
|
|
|
llvm_unreachable("long double not supported yet");
|
|
|
|
case Type::PointerTyID:
|
|
|
|
return PTOGV(((void*(*)())(intptr_t)FPtr)());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-02-07 05:05:23 +00:00
|
|
|
llvm_unreachable("Full-featured argument passing not supported yet!");
|
2010-11-17 16:06:43 +00:00
|
|
|
}
|
2012-03-28 21:46:36 +00:00
|
|
|
|
2014-09-15 17:50:22 +00:00
|
|
|
void *MCJIT::getPointerToNamedFunction(StringRef Name, bool AbortOnFailure) {
|
2013-10-01 01:47:35 +00:00
|
|
|
if (!isSymbolSearchingDisabled()) {
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
void *ptr =
|
|
|
|
reinterpret_cast<void*>(
|
|
|
|
static_cast<uintptr_t>(Resolver.findSymbol(Name).getAddress()));
|
2012-03-28 21:46:36 +00:00
|
|
|
if (ptr)
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// If a LazyFunctionCreator is installed, use it to get/create the function.
|
|
|
|
if (LazyFunctionCreator)
|
|
|
|
if (void *RP = LazyFunctionCreator(Name))
|
|
|
|
return RP;
|
|
|
|
|
|
|
|
if (AbortOnFailure) {
|
|
|
|
report_fatal_error("Program used external function '"+Name+
|
2012-04-29 12:40:47 +00:00
|
|
|
"' which could not be resolved!");
|
2012-03-28 21:46:36 +00:00
|
|
|
}
|
2014-04-24 06:44:33 +00:00
|
|
|
return nullptr;
|
2012-03-28 21:46:36 +00:00
|
|
|
}
|
2012-11-06 18:51:59 +00:00
|
|
|
|
|
|
|
void MCJIT::RegisterJITEventListener(JITEventListener *L) {
|
2014-04-24 06:44:33 +00:00
|
|
|
if (!L)
|
2012-11-06 18:51:59 +00:00
|
|
|
return;
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2012-11-06 18:51:59 +00:00
|
|
|
EventListeners.push_back(L);
|
|
|
|
}
|
2014-11-26 16:54:40 +00:00
|
|
|
|
2012-11-06 18:51:59 +00:00
|
|
|
void MCJIT::UnregisterJITEventListener(JITEventListener *L) {
|
2014-04-24 06:44:33 +00:00
|
|
|
if (!L)
|
2012-11-06 18:51:59 +00:00
|
|
|
return;
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2014-09-02 22:28:02 +00:00
|
|
|
auto I = std::find(EventListeners.rbegin(), EventListeners.rend(), L);
|
2012-11-06 18:51:59 +00:00
|
|
|
if (I != EventListeners.rend()) {
|
|
|
|
std::swap(*I, EventListeners.back());
|
|
|
|
EventListeners.pop_back();
|
|
|
|
}
|
|
|
|
}
|
2014-11-26 16:54:40 +00:00
|
|
|
|
|
|
|
void MCJIT::NotifyObjectEmitted(const object::ObjectFile& Obj,
|
|
|
|
const RuntimeDyld::LoadedObjectInfo &L) {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
MemMgr->notifyObjectLoaded(this, Obj);
|
2012-11-06 18:51:59 +00:00
|
|
|
for (unsigned I = 0, S = EventListeners.size(); I < S; ++I) {
|
2014-11-26 16:54:40 +00:00
|
|
|
EventListeners[I]->NotifyObjectEmitted(Obj, L);
|
2012-11-06 18:51:59 +00:00
|
|
|
}
|
|
|
|
}
|
2014-11-26 16:54:40 +00:00
|
|
|
|
|
|
|
void MCJIT::NotifyFreeingObject(const object::ObjectFile& Obj) {
|
2014-06-20 21:07:14 +00:00
|
|
|
MutexGuard locked(lock);
|
2014-09-03 19:48:09 +00:00
|
|
|
for (JITEventListener *L : EventListeners)
|
2014-09-02 22:28:02 +00:00
|
|
|
L->NotifyFreeingObject(Obj);
|
2012-11-06 18:51:59 +00:00
|
|
|
}
|
2013-10-01 01:47:35 +00:00
|
|
|
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
RuntimeDyld::SymbolInfo
|
|
|
|
LinkingSymbolResolver::findSymbol(const std::string &Name) {
|
|
|
|
auto Result = ParentEngine.findSymbol(Name, false);
|
2013-10-01 16:42:50 +00:00
|
|
|
// If the symbols wasn't found and it begins with an underscore, try again
|
|
|
|
// without the underscore.
|
|
|
|
if (!Result && Name[0] == '_')
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
Result = ParentEngine.findSymbol(Name.substr(1), false);
|
2013-10-01 01:47:35 +00:00
|
|
|
if (Result)
|
|
|
|
return Result;
|
[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
MCJIT.
This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.
The symbol resolution interface is modified slightly, from:
uint64_t getSymbolAddress(const std::string &Name);
to:
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);
The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.
The memory management interface removes the following method:
void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).
The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).
The EngineBuilder class retains the existing method:
EngineBuilder&
setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);
and includes two new methods:
EngineBuilder&
setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);
EngineBuilder&
setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);
Clients should use EITHER:
A single call to setMCJITMemoryManager with an RTDyldMemoryManager.
OR (exclusive)
One call each to each of setMemoryManager and setSymbolResolver.
This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.
If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233509 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 03:37:06 +00:00
|
|
|
if (ParentEngine.isSymbolSearchingDisabled())
|
|
|
|
return nullptr;
|
|
|
|
return ClientResolver->findSymbol(Name);
|
2013-10-01 01:47:35 +00:00
|
|
|
}
|