[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
[Orc][MCJIT][RuntimeDyld] Re-apply r231726 and r231724 with fix suggested by Dave Blaikie. Thanks Dave! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231896 91177308-0d34-0410-b5e6-96231b3b80d8
Temporarily revert r231726 and r231724 as they're breaking the build.: Author: Lang Hames <lhames@gmail.com> Date: Mon Mar 9 23:51:09 2015 +0000 [Orc][MCJIT][RuntimeDyld] Add header that was accidentally left out of r231724. Author: Lang Hames <lhames@gmail.com> Date: Mon Mar 9 23:44:13 2015 +0000 [Orc][MCJIT][RuntimeDyld] Add symbol flags to symbols in RuntimeDyld. Thread the new types through MCJIT and Orc. In particular, add a 'weak' flag. When plumbed through RTDyldMemoryManager, this will allow us to distinguish between weak and strong definitions and find the right ones during symbol resolution. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231731 91177308-0d34-0410-b5e6-96231b3b80d8
[Orc][MCJIT][RuntimeDyld] Add symbol flags to symbols in RuntimeDyld. Thread the new types through MCJIT and Orc. In particular, add a 'weak' flag. When plumbed through RTDyldMemoryManager, this will allow us to distinguish between weak and strong definitions and find the right ones during symbol resolution. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231724 91177308-0d34-0410-b5e6-96231b3b80d8
Orc/JITSymbol.h requires not "Compiler.h" but "DataTypes.h" due to uint64_t. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230214 91177308-0d34-0410-b5e6-96231b3b80d8
[Orc] Move Orc code into a namespace (llvm::orc), update Kaleidoscope code. NFC. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230143 91177308-0d34-0410-b5e6-96231b3b80d8
[Orc] Add a new JITSymbol constructor to build a symbol from an existing address. This constructor is more efficient for symbols that have already been emitted, since it avoids the construction/execution of a std::function. Update the ObjectLinkingLayer to use this new constructor where possible. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229973 91177308-0d34-0410-b5e6-96231b3b80d8
Removing LLVM_EXPLICIT, as MSVC 2012 was the last reason for requiring the macro. NFC; LLVM edition. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229335 91177308-0d34-0410-b5e6-96231b3b80d8
[Orc] Add missing casserts header to JITSymbol.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228675 91177308-0d34-0410-b5e6-96231b3b80d8
[Orc] Fix the MSVC bots by using LLVM_EXPLICIT rather than explicit. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228564 91177308-0d34-0410-b5e6-96231b3b80d8
[Orc] Add a JITSymbol class to the Orc APIs, refactor APIs, update clients. This patch refactors a key piece of the Orc APIs: It removes the *::getSymbolAddress and *::lookupSymbolAddressIn methods, which returned target addresses (uint64_ts), and replaces them with *::findSymbol and *::findSymbolIn respectively, which return instances of the new JITSymbol type. Unlike the old methods, calling findSymbol or findSymbolIn does not cause the symbol to be immediately materialized when found. Instead, the symbol will be materialized if/when the getAddress method is called on the returned JITSymbol. This allows us to query for the existence of symbols without actually materializing them. In the future I expect more information to be attached to the JITSymbol class, for example whether the returned symbol is a weak or strong definition. This will allow us to properly handle weak symbols and multiple definitions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228557 91177308-0d34-0410-b5e6-96231b3b80d8