[ORC] Re-land https://github.com/llvm/llvm-project/pull/81826
This patch adds two plugins: VTuneSupportPlugin.cpp and
JITLoaderVTune.cpp. The testing is done in a manner similar to
llvm-jitlistener. Currently, we only support the old version of Intel
VTune API.
The base class llvm::ThreadPoolInterface will be renamed
llvm::ThreadPool in a subsequent commit.
This is a breaking change: clients who use to create a ThreadPool must
now create a DefaultThreadPool instead.
API clients can now set a MachO::HeaderOptions::BuildVersionOpts field to have
MachOPlatform add an LC_BUILD_VERSION load command to the Mach header for each
JITDylib.
No testcase yet. In the future we'll try to add a MachO parser to the ORC
runtime and extra test options to llvm-jitlink for this.
This commit also incidentally fixes a bug in the MachOBuilder class that lead to
a delegation cycle.
This patch adds two plugins: VTuneSupportPlugin.cpp and
JITLoaderVTune.cpp. The testing is done in a manner similar to
llvm-jitlistener. Currently, we only support the old version of Intel
VTune API.
This pull request is stacked on top of
https://github.com/llvm/llvm-project/pull/81825
The SectCreateMaterializationUnit creates a LinkGraph with a single named
section containing a single named block whose content is given by a
MemoryBuffer. It is intended to support emulation of ld64's -sectcreate option.
Switch the primary implementation of EPC lookupSymbols to be async,
keeping a synchronous wrapper for compatibility. Use the new async
implementation inside EPCDynamicLibrarySearchGenerator to work
working towards a fully async search generator.
Provide an asynchronous lookup API for EPCGenericDylibManager and adopt
that from the SimpleRemoteEPC. This enables an end-to-end async
EPCDynamicLibrarySearchGenerator. Note: currently we keep the current
per-dlhandle lookup model, but a future improvement could do a single
async call for a given lookup operation.
Removes the MaterializationResponsibility::addDependencies and
addDependenciesForAll methods, and transfers dependency registration to
the notifyEmitted operation. The new dependency registration allows
dependencies to be specified for arbitrary subsets of the
MaterializationResponsibility's symbols (rather than just single symbols
or all symbols) via an array of SymbolDependenceGroups (pairs of symbol
sets and corresponding dependencies for that set).
This patch aims to both improve emission performance and simplify
dependence tracking. By eliminating some states (e.g. symbols having
registered dependencies but not yet being resolved or emitted) we make
some errors impossible by construction, and reduce the number of error
cases that we need to check. NonOwningSymbolStringPtrs are used for
dependence tracking under the session lock, which should reduce
ref-counting operations, and intra-emit dependencies are resolved
outside the session lock, which should provide better performance when
JITing concurrently (since some dependence tracking can happen in
parallel).
The Orc C API is updated to account for this change, with the
LLVMOrcMaterializationResponsibilityNotifyEmitted API being modified and
the LLVMOrcMaterializationResponsibilityAddDependencies and
LLVMOrcMaterializationResponsibilityAddDependenciesForAll operations
being removed.
The JITLink AArch32 backend reached feature-parity with RuntimeDyld
on ELF-based systems. This patch changes the default JIT-linker in Orc's
LLJIT for these platforms.
This allows us to run clang-repl with JITLink on ARM and use all the
features we had with RuntimeDyld before. All existing tests for
clang-repl are passing.
Add a HeaderOptions struct that can be used to configure commonly-used
load commands LC_ID_DYLIB, LC_LOAD_DYLIB, and LC_RPATH when setupDylib
creates a mach-o header.
Adds a function to create a LinkGraph of absolute symbols, and a
callback in dynamic library search generators to enable using it to
expose its symbols to the platform/orc runtime. This allows e.g. using
__orc_rt_run_program to run a precompiled function that was found via
dlsym. Ideally we would use this in llvm-jitlink's own search generator,
but it will require more work to align with the Process/Platform
JITDylib split, so not handled here.
As part of this change we need to handle LinkGraphs that only have
absolute symbols.
This migrates the dylib manager lookup and related APIs to replace
ExecutorAddress with ExecutorSymbolDef so that in the future we can
model JITSymbolFlags for these symbols. The current change should be NFC
as we are only setting the Exported symbol flag.
https://github.com/llvm/llvm-project/pull/76236 introduced the forth
copy and it was time to deduplicate. This patch brings it back to 2,
one in OrcTargetProcess and one in legacy ExecutionEngine.
For out-of-process support the DynamicLibrarySearchGenerator must go
through EPC, otherwise we lookup symbols from the host and not the
target process.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
LLJIT users may want to customize their native platform setup beyond what the
ExecutorNativePlatform helper permits. In this case LLJIT users can construct
the platform instance manually, and then add an ORCPlatformSupport instance
to forward initialize/deinitialize operations to the ORC runtime.
SimpleMachOHeaderMU can be used as a convenient base for classes that create
custom MachO headers. Instances of these custom classes can be used by passing
a MachOHeaderMUBuilder using the MachOPlatform extensions added in ef314d39b92.
Allow C-API users to debug their JITed code via the GDB JIT Interface.
This is currently supported on ELF and MachO based platforms. On
other systems `LLVMOrcLLJITEnableDebugSupport()` returns an error.
This patch adds a new C-API header `LLJITUtils.h`, which can host
further advanced JIT features in the future. Using the header requires
linking against LLVMOrcDebugging.
1. Prevent deadlock by unlocking JDStatesMutex when calling back to the
controller to request a push of new symbols. (If JDStatesMutex is locked
then the push operation can't register the new symbols, and so can't
complete).
2. Record MachOPlatform runtime symbols during bootstrap and attach their
registration to the bootstrap-completion graph, similar to the way that
deferred allocation actions are handled. We can't register the symbols
the normal way during bootstrap since the symbol registration function is
itself in the process of being materialized.
3. Add dlsym testcases to exercise these fixes.
Replaces an llvm::cast that assumed that all Binary instances were either
Archive or MachOUniversalBinary instances with a dyn_cast. The cast was
triggering an assert in StaticLibraryDefinitionGenerator::Load if that method
was given a path or MemoryBuffer containing a relocatable object file.
Switching to dyn_cast causes the operation to error out with a bad-format
error as expected.
Fixes rdar://119262300
HeaderAddr shouldn't be a member variable of MachOPlatformPlugin: there's only
one plugin instance shared between all JITDylibs, so the shared HeaderAddr will
be overwritten in an unpredictable and unsafe way. We haven't seen any issues
due to this yet, but it triggered failures during testing of an upcoming
llvm-jitlink patch (e.g. ORC-RT test Darwin/x86-64/jit-re-dlopen-trivial.S).
This patch pre-fixes the issue in advance of the llvm-jitlink patch landing.
This patch also removes some stale debugging output in MachOPlatform.
Adds symbol tables to the JITDylibState struct in the ORC runtime
MachOPlatformRuntimeState class. This table will hold the addresses of
materialized symbols (registered by a new JITLink pass in MachOPlatform),
allowing these to be looked up in the executor without an IPC request to the
controller.
The old lookup-symbols callback (made by the runtime in response to dlsym
lookups) is replaced with a push-symbols callback that can trigger
materialization of requested symbols.
Holding a symbol table on the executor side should make repeat calls to dlsym
(and other symbol lookup operations) cheaper since the IPC to trigger
materialization happens at most once per symbol. It should also enable us (at
some point in the future) to symbolicate backtraces in JIT'd code even if the
controller process is gone (e.g. detached or crashed). The trade-off for this
is increased memory consumption in the executor and larger JIT'd data transfers
(since symbol names are now transferred to the executor unconditionally, even
though they may never be used).
SymbolStringPoolEntryUnsafe provides unsafe access to SymbolStringPtr objects,
allowing clients to manually retain and release pool entries, or consume or
create SymbolStringPtr instances without affecting an entry's ref-count. This
can be useful when writing C APIs that need to handle SymbolStringPtrs.
As part of this patch the LLVM-C API implementation is updated to use the new
utility, rather than the old, private OrcV2CAPIHelper utility.
The system linker merges __objc_imageinfo flags values to select a
compatible set of flags using the minimum swift version and only
erroring on incompatible ABIs. Match that behaviour in the orc macho
platform. One wrinkle is that the JIT can add new objects after the
dylib is running code. In that case we only check for known incompatible
flags and ignore the swift version. It's too late to change the flags at
that point and swift version is unlikely to change runtime behaviour in
practice.
Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
support::endianness with llvm::endianness.
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
support::endianness::{big,little,native} with
llvm::endianness::{big,little,native}.
system_endianness() just returns llvm::endianness::native, a
compile-time constant equivalent to std::native in C++20. This patch
deprecates system_endianness() while replacing all invocations of
system_endianness() with llvm::endianness::native.
While we are at it, this patch replaces
llvm::support::endianness::{big,little} with
llvm::endianness::{big,little} in those statements that happen to call
system_endianness(). It does not go out of its way to replace other
occurrences of llvm::support::endianness::{big,little}.
Without this patch, we pass G.getEndianness() as one of the parameters
to DWARFContext::create. The problem is that G.getEndianness() is of:
enum endianness {big, little, native};
whereas DWARFContext::create is expecting "bool isLittleEndian". That
is, we are relying on an implicit conversion to convert big and little
to false and true, respectively.
When we migrate llvm::support::endianness to std::endian in future, we
can no longer rely on an implicit conversion because std::endian is
declared with "enum class". Even if we could, the conversion would
not be guaranteed to work because, for example, libcxx defines:
enum class endian {
little = 0xDEAD,
big = 0xFACE,
:
where big and little are not boolean values.
This patch fixes the problem by properly converting G.getEndianness()
to a boolean value.
At line 191, `addSymbol` takes the name by reference but does not make
an internal copy to the string, meaning the local
`optional<std::string>` would get freed and leave Orc with a dangling
pointer. Fix this by just using an `optional<StringRef>` instead.
Instead of ConstantExpr::getCast() with a fixed opcode, use the
corresponding getXYZ methods instead. For the one place creating
a pointer bitcast drop it entirely, as this is redundant with
opaque pointers.
This re-applies db51e572893, which was reverted in 05b1a2cb3e6 due to bot
failures. The DebuggerSupportPlugin now depends on DWARF, so it has been moved
to the new OrcDebugging library (as has the enableDebuggerSupport API).
This patch adds line numbers to perf jitdump records emitted by the
PerfSupportPlugin, by parsing and using a DWARFContext from preserved debug
sections.
To avoid making the OrcJIT library depend on DebugInfoDWARF this patch
introduces a new OrcDebugging library.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D146391
The *Policy suffix came from the earlier MemAllocPolicy type, where it was
included to distinguish the type from a memory-allocation operation.
MemLifetime is a noun already, so the *Policy suffix is just dead weight now.
This re-applies e1a5bb59b91, which was reverted in e5f169f91a8 due to LSan
failures on some bots (see https://github.com/llvm/llvm-project/issues/67586).
The LSan failures were not caused by this patch (just exposed by it), so LSan
was disabled for the failing test in 47625fea5e3. This should be safe to
re-land now.
This change means that debugger support only needs to be linked in if it's
used. The code size of debugger support is expected to increase as we improve
it (e.g. pulling in DWARF parsing), so making it an optional extra is useful
for controlling final binary sizes.
This function will be run prior to platform setup to provide LLJIT clients with
a chance to customize the LLJIT instance (e.g. install plugins) before the JIT
runtime is loaded.
The motivating use-case is debugger support: We want to install the debugger
plugin before the runtime is loaded (during platform setup) so that the runtime
itself can be debugged. A patch to do this will be committed shortly.
