llvm-project/llvm/lib/ExecutionEngine/Orc/LazyReexports.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

209 lines
6.7 KiB
C++
Raw Normal View History

//===---------- LazyReexports.cpp - Utilities for lazy reexports ----------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "llvm/ExecutionEngine/Orc/LazyReexports.h"
#include "llvm/ADT/Triple.h"
#include "llvm/ExecutionEngine/Orc/OrcABISupport.h"
#define DEBUG_TYPE "orc"
namespace llvm {
namespace orc {
LazyCallThroughManager::LazyCallThroughManager(
ExecutionSession &ES, JITTargetAddress ErrorHandlerAddr,
std::unique_ptr<TrampolinePool> TP)
: ES(ES), ErrorHandlerAddr(ErrorHandlerAddr), TP(std::move(TP)) {}
Expected<JITTargetAddress> LazyCallThroughManager::getCallThroughTrampoline(
JITDylib &SourceJD, SymbolStringPtr SymbolName,
NotifyResolvedFunction NotifyResolved) {
std::lock_guard<std::mutex> Lock(LCTMMutex);
auto Trampoline = TP->getTrampoline();
if (!Trampoline)
return Trampoline.takeError();
Reexports[*Trampoline] = std::make_pair(&SourceJD, std::move(SymbolName));
Notifiers[*Trampoline] = std::move(NotifyResolved);
return *Trampoline;
}
JITTargetAddress
LazyCallThroughManager::callThroughToSymbol(JITTargetAddress TrampolineAddr) {
JITDylib *SourceJD = nullptr;
SymbolStringPtr SymbolName;
{
std::lock_guard<std::mutex> Lock(LCTMMutex);
auto I = Reexports.find(TrampolineAddr);
if (I == Reexports.end())
return ErrorHandlerAddr;
SourceJD = I->second.first;
SymbolName = I->second.second;
}
[ORC][JITLink] Add support for weak references, and improve handling of static libraries. This patch substantially updates ORCv2's lookup API in order to support weak references, and to better support static archives. Key changes: -- Each symbol being looked for is now associated with a SymbolLookupFlags value. If the associated value is SymbolLookupFlags::RequiredSymbol then the symbol must be defined in one of the JITDylibs being searched (or be able to be generated in one of these JITDylibs via an attached definition generator) or the lookup will fail with an error. If the associated value is SymbolLookupFlags::WeaklyReferencedSymbol then the symbol is permitted to be undefined, in which case it will simply not appear in the resulting SymbolMap if the rest of the lookup succeeds. Since lookup now requires these flags for each symbol, the lookup method now takes an instance of a new SymbolLookupSet type rather than a SymbolNameSet. SymbolLookupSet is a vector-backed set of (name, flags) pairs. Clients are responsible for ensuring that the set property (i.e. unique elements) holds, though this is usually simple and SymbolLookupSet provides convenience methods to support this. -- Lookups now have an associated LookupKind value, which is either LookupKind::Static or LookupKind::DLSym. Definition generators can inspect the lookup kind when determining whether or not to generate new definitions. The StaticLibraryDefinitionGenerator is updated to only pull in new objects from the archive if the lookup kind is Static. This allows lookup to be re-used to emulate dlsym for JIT'd symbols without pulling in new objects from archives (which would not happen in a normal dlsym call). -- JITLink is updated to allow externals to be assigned weak linkage, and weak externals now use the SymbolLookupFlags::WeaklyReferencedSymbol value for lookups. Unresolved weak references will be assigned the default value of zero. Since this patch was modifying the lookup API anyway, it alo replaces all of the "MatchNonExported" boolean arguments with a "JITDylibLookupFlags" enum for readability. If a JITDylib's associated value is JITDylibLookupFlags::MatchExportedSymbolsOnly then the lookup will only match against exported (non-hidden) symbols in that JITDylib. If a JITDylib's associated value is JITDylibLookupFlags::MatchAllSymbols then the lookup will match against any symbol defined in the JITDylib.
2019-11-26 13:57:27 +08:00
auto LookupResult = ES.lookup(
makeJITDylibSearchOrder(SourceJD, JITDylibLookupFlags::MatchAllSymbols),
[ORC] Add generic initializer/deinitializer support. Initializers and deinitializers are used to implement C++ static constructors and destructors, runtime registration for some languages (e.g. with the Objective-C runtime for Objective-C/C++ code) and other tasks that would typically be performed when a shared-object/dylib is loaded or unloaded by a statically compiled program. MCJIT and ORC have historically provided limited support for discovering and running initializers/deinitializers by scanning the llvm.global_ctors and llvm.global_dtors variables and recording the functions to be run. This approach suffers from several drawbacks: (1) It only works for IR inputs, not for object files (including cached JIT'd objects). (2) It only works for initializers described by llvm.global_ctors and llvm.global_dtors, however not all initializers are described in this way (Objective-C, for example, describes initializers via specially named metadata sections). (3) To make the initializer/deinitializer functions described by llvm.global_ctors and llvm.global_dtors searchable they must be promoted to extern linkage, polluting the JIT symbol table (extra care must be taken to ensure this promotion does not result in symbol name clashes). This patch introduces several interdependent changes to ORCv2 to support the construction of new initialization schemes, and includes an implementation of a backwards-compatible llvm.global_ctor/llvm.global_dtor scanning scheme, and a MachO specific scheme that handles Objective-C runtime registration (if the Objective-C runtime is available) enabling execution of LLVM IR compiled from Objective-C and Swift. The major changes included in this patch are: (1) The MaterializationUnit and MaterializationResponsibility classes are extended to describe an optional "initializer" symbol for the module (see the getInitializerSymbol method on each class). The presence or absence of this symbol indicates whether the module contains any initializers or deinitializers. The initializer symbol otherwise behaves like any other: searching for it triggers materialization. (2) A new Platform interface is introduced in llvm/ExecutionEngine/Orc/Core.h which provides the following callback interface: - Error setupJITDylib(JITDylib &JD): Can be used to install standard symbols in JITDylibs upon creation. E.g. __dso_handle. - Error notifyAdding(JITDylib &JD, const MaterializationUnit &MU): Generally used to record initializer symbols. - Error notifyRemoving(JITDylib &JD, VModuleKey K): Used to notify a platform that a module is being removed. Platform implementations can use these callbacks to track outstanding initializers and implement a platform-specific approach for executing them. For example, the MachOPlatform installs a plugin in the JIT linker to scan for both __mod_inits sections (for C++ static constructors) and ObjC metadata sections. If discovered, these are processed in the usual platform order: Objective-C registration is carried out first, then static initializers are executed, ensuring that calls to Objective-C from static initializers will be safe. This patch updates LLJIT to use the new scheme for initialization. Two LLJIT::PlatformSupport classes are implemented: A GenericIR platform and a MachO platform. The GenericIR platform implements a modified version of the previous llvm.global-ctor scraping scheme to provide support for Windows and Linux. LLJIT's MachO platform uses the MachOPlatform class to provide MachO specific initialization as described above. Reviewers: sgraenitz, dblaikie Subscribers: mgorny, hiraditya, mgrang, ributzka, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74300
2019-12-16 18:50:40 +08:00
SymbolName, SymbolState::Ready);
if (!LookupResult) {
ES.reportError(LookupResult.takeError());
return ErrorHandlerAddr;
}
auto ResolvedAddr = LookupResult->getAddress();
NotifyResolvedFunction NotifyResolved;
{
std::lock_guard<std::mutex> Lock(LCTMMutex);
auto I = Notifiers.find(TrampolineAddr);
if (I != Notifiers.end()) {
NotifyResolved = std::move(I->second);
Notifiers.erase(I);
}
}
if (NotifyResolved) {
if (auto Err = NotifyResolved(ResolvedAddr)) {
ES.reportError(std::move(Err));
return ErrorHandlerAddr;
}
}
return ResolvedAddr;
}
Expected<std::unique_ptr<LazyCallThroughManager>>
createLocalLazyCallThroughManager(const Triple &T, ExecutionSession &ES,
JITTargetAddress ErrorHandlerAddr) {
switch (T.getArch()) {
default:
return make_error<StringError>(
std::string("No callback manager available for ") + T.str(),
inconvertibleErrorCode());
case Triple::aarch64:
case Triple::aarch64_32:
return LocalLazyCallThroughManager::Create<OrcAArch64>(ES,
ErrorHandlerAddr);
case Triple::x86:
return LocalLazyCallThroughManager::Create<OrcI386>(ES, ErrorHandlerAddr);
case Triple::mips:
return LocalLazyCallThroughManager::Create<OrcMips32Be>(ES,
ErrorHandlerAddr);
case Triple::mipsel:
return LocalLazyCallThroughManager::Create<OrcMips32Le>(ES,
ErrorHandlerAddr);
case Triple::mips64:
case Triple::mips64el:
return LocalLazyCallThroughManager::Create<OrcMips64>(ES, ErrorHandlerAddr);
case Triple::x86_64:
if (T.getOS() == Triple::OSType::Win32)
return LocalLazyCallThroughManager::Create<OrcX86_64_Win32>(
ES, ErrorHandlerAddr);
else
return LocalLazyCallThroughManager::Create<OrcX86_64_SysV>(
ES, ErrorHandlerAddr);
}
}
LazyReexportsMaterializationUnit::LazyReexportsMaterializationUnit(
LazyCallThroughManager &LCTManager, IndirectStubsManager &ISManager,
JITDylib &SourceJD, SymbolAliasMap CallableAliases, ImplSymbolMap *SrcJDLoc,
VModuleKey K)
[ORC] Add generic initializer/deinitializer support. Initializers and deinitializers are used to implement C++ static constructors and destructors, runtime registration for some languages (e.g. with the Objective-C runtime for Objective-C/C++ code) and other tasks that would typically be performed when a shared-object/dylib is loaded or unloaded by a statically compiled program. MCJIT and ORC have historically provided limited support for discovering and running initializers/deinitializers by scanning the llvm.global_ctors and llvm.global_dtors variables and recording the functions to be run. This approach suffers from several drawbacks: (1) It only works for IR inputs, not for object files (including cached JIT'd objects). (2) It only works for initializers described by llvm.global_ctors and llvm.global_dtors, however not all initializers are described in this way (Objective-C, for example, describes initializers via specially named metadata sections). (3) To make the initializer/deinitializer functions described by llvm.global_ctors and llvm.global_dtors searchable they must be promoted to extern linkage, polluting the JIT symbol table (extra care must be taken to ensure this promotion does not result in symbol name clashes). This patch introduces several interdependent changes to ORCv2 to support the construction of new initialization schemes, and includes an implementation of a backwards-compatible llvm.global_ctor/llvm.global_dtor scanning scheme, and a MachO specific scheme that handles Objective-C runtime registration (if the Objective-C runtime is available) enabling execution of LLVM IR compiled from Objective-C and Swift. The major changes included in this patch are: (1) The MaterializationUnit and MaterializationResponsibility classes are extended to describe an optional "initializer" symbol for the module (see the getInitializerSymbol method on each class). The presence or absence of this symbol indicates whether the module contains any initializers or deinitializers. The initializer symbol otherwise behaves like any other: searching for it triggers materialization. (2) A new Platform interface is introduced in llvm/ExecutionEngine/Orc/Core.h which provides the following callback interface: - Error setupJITDylib(JITDylib &JD): Can be used to install standard symbols in JITDylibs upon creation. E.g. __dso_handle. - Error notifyAdding(JITDylib &JD, const MaterializationUnit &MU): Generally used to record initializer symbols. - Error notifyRemoving(JITDylib &JD, VModuleKey K): Used to notify a platform that a module is being removed. Platform implementations can use these callbacks to track outstanding initializers and implement a platform-specific approach for executing them. For example, the MachOPlatform installs a plugin in the JIT linker to scan for both __mod_inits sections (for C++ static constructors) and ObjC metadata sections. If discovered, these are processed in the usual platform order: Objective-C registration is carried out first, then static initializers are executed, ensuring that calls to Objective-C from static initializers will be safe. This patch updates LLJIT to use the new scheme for initialization. Two LLJIT::PlatformSupport classes are implemented: A GenericIR platform and a MachO platform. The GenericIR platform implements a modified version of the previous llvm.global-ctor scraping scheme to provide support for Windows and Linux. LLJIT's MachO platform uses the MachOPlatform class to provide MachO specific initialization as described above. Reviewers: sgraenitz, dblaikie Subscribers: mgorny, hiraditya, mgrang, ributzka, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74300
2019-12-16 18:50:40 +08:00
: MaterializationUnit(extractFlags(CallableAliases), nullptr, std::move(K)),
LCTManager(LCTManager), ISManager(ISManager), SourceJD(SourceJD),
[ORC] Add generic initializer/deinitializer support. Initializers and deinitializers are used to implement C++ static constructors and destructors, runtime registration for some languages (e.g. with the Objective-C runtime for Objective-C/C++ code) and other tasks that would typically be performed when a shared-object/dylib is loaded or unloaded by a statically compiled program. MCJIT and ORC have historically provided limited support for discovering and running initializers/deinitializers by scanning the llvm.global_ctors and llvm.global_dtors variables and recording the functions to be run. This approach suffers from several drawbacks: (1) It only works for IR inputs, not for object files (including cached JIT'd objects). (2) It only works for initializers described by llvm.global_ctors and llvm.global_dtors, however not all initializers are described in this way (Objective-C, for example, describes initializers via specially named metadata sections). (3) To make the initializer/deinitializer functions described by llvm.global_ctors and llvm.global_dtors searchable they must be promoted to extern linkage, polluting the JIT symbol table (extra care must be taken to ensure this promotion does not result in symbol name clashes). This patch introduces several interdependent changes to ORCv2 to support the construction of new initialization schemes, and includes an implementation of a backwards-compatible llvm.global_ctor/llvm.global_dtor scanning scheme, and a MachO specific scheme that handles Objective-C runtime registration (if the Objective-C runtime is available) enabling execution of LLVM IR compiled from Objective-C and Swift. The major changes included in this patch are: (1) The MaterializationUnit and MaterializationResponsibility classes are extended to describe an optional "initializer" symbol for the module (see the getInitializerSymbol method on each class). The presence or absence of this symbol indicates whether the module contains any initializers or deinitializers. The initializer symbol otherwise behaves like any other: searching for it triggers materialization. (2) A new Platform interface is introduced in llvm/ExecutionEngine/Orc/Core.h which provides the following callback interface: - Error setupJITDylib(JITDylib &JD): Can be used to install standard symbols in JITDylibs upon creation. E.g. __dso_handle. - Error notifyAdding(JITDylib &JD, const MaterializationUnit &MU): Generally used to record initializer symbols. - Error notifyRemoving(JITDylib &JD, VModuleKey K): Used to notify a platform that a module is being removed. Platform implementations can use these callbacks to track outstanding initializers and implement a platform-specific approach for executing them. For example, the MachOPlatform installs a plugin in the JIT linker to scan for both __mod_inits sections (for C++ static constructors) and ObjC metadata sections. If discovered, these are processed in the usual platform order: Objective-C registration is carried out first, then static initializers are executed, ensuring that calls to Objective-C from static initializers will be safe. This patch updates LLJIT to use the new scheme for initialization. Two LLJIT::PlatformSupport classes are implemented: A GenericIR platform and a MachO platform. The GenericIR platform implements a modified version of the previous llvm.global-ctor scraping scheme to provide support for Windows and Linux. LLJIT's MachO platform uses the MachOPlatform class to provide MachO specific initialization as described above. Reviewers: sgraenitz, dblaikie Subscribers: mgorny, hiraditya, mgrang, ributzka, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74300
2019-12-16 18:50:40 +08:00
CallableAliases(std::move(CallableAliases)), AliaseeTable(SrcJDLoc) {}
StringRef LazyReexportsMaterializationUnit::getName() const {
return "<Lazy Reexports>";
}
void LazyReexportsMaterializationUnit::materialize(
MaterializationResponsibility R) {
auto RequestedSymbols = R.getRequestedSymbols();
SymbolAliasMap RequestedAliases;
for (auto &RequestedSymbol : RequestedSymbols) {
auto I = CallableAliases.find(RequestedSymbol);
assert(I != CallableAliases.end() && "Symbol not found in alias map?");
RequestedAliases[I->first] = std::move(I->second);
CallableAliases.erase(I);
}
if (!CallableAliases.empty())
R.replace(lazyReexports(LCTManager, ISManager, SourceJD,
std::move(CallableAliases), AliaseeTable));
IndirectStubsManager::StubInitsMap StubInits;
for (auto &Alias : RequestedAliases) {
auto CallThroughTrampoline = LCTManager.getCallThroughTrampoline(
SourceJD, Alias.second.Aliasee,
[&ISManager = this->ISManager,
StubSym = Alias.first](JITTargetAddress ResolvedAddr) -> Error {
return ISManager.updatePointer(*StubSym, ResolvedAddr);
});
if (!CallThroughTrampoline) {
SourceJD.getExecutionSession().reportError(
CallThroughTrampoline.takeError());
R.failMaterialization();
return;
}
StubInits[*Alias.first] =
std::make_pair(*CallThroughTrampoline, Alias.second.AliasFlags);
}
if (AliaseeTable != nullptr && !RequestedAliases.empty())
AliaseeTable->trackImpls(RequestedAliases, &SourceJD);
if (auto Err = ISManager.createStubs(StubInits)) {
SourceJD.getExecutionSession().reportError(std::move(Err));
R.failMaterialization();
return;
}
SymbolMap Stubs;
for (auto &Alias : RequestedAliases)
Stubs[Alias.first] = ISManager.findStub(*Alias.first, false);
// No registered dependencies, so these calls cannot fail.
cantFail(R.notifyResolved(Stubs));
cantFail(R.notifyEmitted());
}
void LazyReexportsMaterializationUnit::discard(const JITDylib &JD,
const SymbolStringPtr &Name) {
assert(CallableAliases.count(Name) &&
"Symbol not covered by this MaterializationUnit");
CallableAliases.erase(Name);
}
SymbolFlagsMap
LazyReexportsMaterializationUnit::extractFlags(const SymbolAliasMap &Aliases) {
SymbolFlagsMap SymbolFlags;
for (auto &KV : Aliases) {
assert(KV.second.AliasFlags.isCallable() &&
"Lazy re-exports must be callable symbols");
SymbolFlags[KV.first] = KV.second.AliasFlags;
}
return SymbolFlags;
}
} // End namespace orc.
} // End namespace llvm.