6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2025-07-25 13:24:46 +00:00
Code Issues Projects Releases Wiki Activity

[MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through

Browse Source 
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
This commit is contained in:
Lang Hames
2015-03-30 03:37:06 +00:00
parent 8af7cb0001
commit da62155c11
38 changed files with 746 additions and 556 deletions
Download Patch File Download Diff File Expand all files Collapse all files

136
include/llvm/ExecutionEngine/RTDyldMemoryManager.h
View File

@@ -14,6 +14,7 @@
#ifndef LLVM_EXECUTIONENGINE_RTDYLDMEMORYMANAGER_H
#define LLVM_EXECUTIONENGINE_RTDYLDMEMORYMANAGER_H
#include "RuntimeDyld.h"
#include "llvm-c/ExecutionEngine.h"
#include "llvm/ADT/StringRef.h"
#include "llvm/Support/CBindingWrapping.h"
@@ -27,89 +28,91 @@ class ExecutionEngine;
class ObjectFile;
}
class MCJITMemoryManager : public RuntimeDyld::MemoryManager {
public:
/// This method is called after an object has been loaded into memory but
/// before relocations are applied to the loaded sections. The object load
/// may have been initiated by MCJIT to resolve an external symbol for another
/// object that is being finalized. In that case, the object about which
/// the memory manager is being notified will be finalized immediately after
/// the memory manager returns from this call.
///
/// Memory managers which are preparing code for execution in an external
/// address space can use this call to remap the section addresses for the
/// newly loaded object.
virtual void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
};
// RuntimeDyld clients often want to handle the memory management of
// what gets placed where. For JIT clients, this is the subset of
// JITMemoryManager required for dynamic loading of binaries.
//
// FIXME: As the RuntimeDyld fills out, additional routines will be needed
// for the varying types of objects to be allocated.
class RTDyldMemoryManager {
class RTDyldMemoryManager : public MCJITMemoryManager,
public RuntimeDyld::SymbolResolver {
RTDyldMemoryManager(const RTDyldMemoryManager&) = delete;
void operator=(const RTDyldMemoryManager&) = delete;
public:
RTDyldMemoryManager() {}
virtual ~RTDyldMemoryManager();
/// Allocate a memory block of (at least) the given size suitable for
/// executable code. The SectionID is a unique identifier assigned by the JIT
/// engine, and optionally recorded by the memory manager to access a loaded
/// section.
virtual uint8_t *allocateCodeSection(
uintptr_t Size, unsigned Alignment, unsigned SectionID,
StringRef SectionName) = 0;
/// Allocate a memory block of (at least) the given size suitable for data.
/// The SectionID is a unique identifier assigned by the JIT engine, and
/// optionally recorded by the memory manager to access a loaded section.
virtual uint8_t *allocateDataSection(
uintptr_t Size, unsigned Alignment, unsigned SectionID,
StringRef SectionName, bool IsReadOnly) = 0;
/// Inform the memory manager about the total amount of memory required to
/// allocate all sections to be loaded:
/// \p CodeSize - the total size of all code sections
/// \p DataSizeRO - the total size of all read-only data sections
/// \p DataSizeRW - the total size of all read-write data sections
///
/// Note that by default the callback is disabled. To enable it
/// redefine the method needsToReserveAllocationSpace to return true.
virtual void reserveAllocationSpace(
uintptr_t CodeSize, uintptr_t DataSizeRO, uintptr_t DataSizeRW) { }
/// Override to return true to enable the reserveAllocationSpace callback.
virtual bool needsToReserveAllocationSpace() { return false; }
/// Register the EH frames with the runtime so that c++ exceptions work.
///
/// \p Addr parameter provides the local address of the EH frame section
/// data, while \p LoadAddr provides the address of the data in the target
/// address space. If the section has not been remapped (which will usually
/// be the case for local execution) these two values will be the same.
virtual void registerEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size);
virtual void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size);
void registerEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size) override;
void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size) override;
/// This method returns the address of the specified function or variable in
/// the current process.
static uint64_t getSymbolAddressInProcess(const std::string &Name);
/// Legacy symbol lookup - DEPRECATED! Please override findSymbol instead.
///
/// This method returns the address of the specified function or variable.
/// It is used to resolve symbols during module linking.
virtual uint64_t getSymbolAddress(const std::string &Name) {
return getSymbolAddressInProcess(Name);
}
/// This method returns the address of the specified symbol if it exists
/// within the logical dynamic library represented by this
/// RTDyldMemoryManager. Unlike getSymbolAddress, queries through this
/// interface should return addresses for hidden symbols.
/// This method returns a RuntimeDyld::SymbolInfo for the specified function
/// or variable. It is used to resolve symbols during module linking.
///
/// This is of particular importance for the Orc JIT APIs, which support lazy
/// compilation by breaking up modules: Each of those broken out modules
/// must be able to resolve hidden symbols provided by the others. Clients
/// writing memory managers for MCJIT can usually ignore this method.
/// By default this falls back on the legacy lookup method:
/// 'getSymbolAddress'. The address returned by getSymbolAddress is treated as
/// a strong, exported symbol, consistent with historical treatment by
/// RuntimeDyld.
///
/// This method will be queried by RuntimeDyld when checking for previous
/// definitions of common symbols. It will *not* be queried by default when
/// resolving external symbols (this minimises the link-time overhead for
/// MCJIT clients who don't care about Orc features). If you are writing a
/// RTDyldMemoryManager for Orc and want "external" symbol resolution to
/// search the logical dylib, you should override your getSymbolAddress
/// method call this method directly.
/// Clients writing custom RTDyldMemoryManagers are encouraged to override
/// this method and return a SymbolInfo with the flags set correctly. This is
/// necessary for RuntimeDyld to correctly handle weak and non-exported symbols.
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name) override {
return RuntimeDyld::SymbolInfo(getSymbolAddress(Name),
JITSymbolFlags::Exported);
}
/// Legacy symbol lookup -- DEPRECATED! Please override
/// findSymbolInLogicalDylib instead.
///
/// Default to treating all modules as separate.
virtual uint64_t getSymbolAddressInLogicalDylib(const std::string &Name) {
return 0;
}
/// Default to treating all modules as separate.
///
/// By default this falls back on the legacy lookup method:
/// 'getSymbolAddressInLogicalDylib'. The address returned by
/// getSymbolAddressInLogicalDylib is treated as a strong, exported symbol,
/// consistent with historical treatment by RuntimeDyld.
///
/// Clients writing custom RTDyldMemoryManagers are encouraged to override
/// this method and return a SymbolInfo with the flags set correctly. This is
/// necessary for RuntimeDyld to correctly handle weak and non-exported symbols.
RuntimeDyld::SymbolInfo
findSymbolInLogicalDylib(const std::string &Name) override {
return RuntimeDyld::SymbolInfo(getSymbolAddressInLogicalDylib(Name),
JITSymbolFlags::Exported);
}
/// This method returns the address of the specified function. As such it is
/// only useful for resolving library symbols, not code generated symbols.
///
@@ -121,30 +124,6 @@ public:
/// MCJIT or RuntimeDyld. Use getSymbolAddress instead.
virtual void *getPointerToNamedFunction(const std::string &Name,
bool AbortOnFailure = true);
/// This method is called after an object has been loaded into memory but
/// before relocations are applied to the loaded sections. The object load
/// may have been initiated by MCJIT to resolve an external symbol for another
/// object that is being finalized. In that case, the object about which
/// the memory manager is being notified will be finalized immediately after
/// the memory manager returns from this call.
///
/// Memory managers which are preparing code for execution in an external
/// address space can use this call to remap the section addresses for the
/// newly loaded object.
virtual void notifyObjectLoaded(ExecutionEngine *EE,
const object::ObjectFile &) {}
/// This method is called when object loading is complete and section page
/// permissions can be applied. It is up to the memory manager implementation
/// to decide whether or not to act on this method. The memory manager will
/// typically allocate all sections as read-write and then apply specific
/// permissions when this method is called. Code sections cannot be executed
/// until this function has been called. In addition, any cache coherency
/// operations needed to reliably use the memory are also performed.
///
/// Returns true if an error occurred, false otherwise.
virtual bool finalizeMemory(std::string *ErrMsg = nullptr) = 0;
};
// Create wrappers for C Binding types (see CBindingWrapping.h).
@@ -153,4 +132,5 @@ DEFINE_SIMPLE_CONVERSION_FUNCTIONS(
} // namespace llvm
#endif