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 ef314d39b9.
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.
Specifying relocation fixup constants with name and type facilitates
readability and compile-time checks. The `FixupInfo<EdgeKind>` facade
organizes the information into entries per relocation type and provides
uniform access across Arm and Thumb relocations. Since it uses template
specializations, it doesn't limit potential entries. We cannot access
the entries dynamically though, because `EdgeKind` must be given as a
compile-time constant.
With this patch we populate a static lookup table on-demand and use it
for dynamic access in opcode-checks.
Reading implicit addend from a relocation site doesn't require a complete
`LinkGraph` edge. The operation is independent from `TargetSymbol`,
but constructing an `Edge` instance required one. This patch fixes the
inconsistency and simplifies some setup code from the error unittests.
Furthermore this patch prepares for the `Arm`/`Thumb`/`Data` helper
functions to be turned into implementation details. Exposing them in the
API causes unfortunate inconsistencies that we don't want to error-check
all the time, e.g. passing `Thumb_Call` to `readAddendArm()`.
Support for ELF::R_ARM_THM_MOVW_PREL_NC and ELF::R_ARM_THM_MOVT_PREL
is added. Move instructions with PC-relative immediates can be handled
in Thumb mode with this addition.
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.
The pass only requires that it can determine a uniquely identified
target at some offsets. Multiple relocations at the same offset are fine
otherwise and will be required when adding exception handling support
for RISC-V.
These files satisfy all of the following:
- misc-include-cleaner indicates that these files do not need
Endian.h.
- They do not mention "endian" anywhere.
- They do not include any *.inc or *.def, which could need
llvm::support::endian.
Currently, the interpreter does not initialize `undef` constants of
aggregate types correctly (with respect to arrays).
The initialization of the array elements is skipped although it is valid
to directly write to them. Instructions like
`insertvalue {i32, [4 x i32]} undef, i32 1, 1, 2` therefore lead to a
crash.
This is fixed by initializing array values just as fixed-size vectors or
structs.
Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class. This patch replaces
{big,little,native} with llvm::endianness::{big,little,native}.
This patch completes the migration to llvm::endianness and
llvm::endianness::{big,little,native}. I'll post a separate patch to
remove the migration helpers in llvm/Support/Endian.h:
using endianness = llvm::endianness;
constexpr llvm::endianness big = llvm::endianness::big;
constexpr llvm::endianness little = llvm::endianness::little;
constexpr llvm::endianness native = llvm::endianness::native;
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}.
This restores the pre-b9383a86b8f behavior. Most platforms / compilers don't
add relocations for CIEs, however they're not prohibited and we want objects
that contain them to remain loadable.
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}.
* Remove unused variable.
* Error on existing edge at CIE pointer field.
* Simplify CFI processing in `EHFrameEdgeFixer`: The code expects
`DWARFRecordSectionSplitter` to split each CFI record into its own
block, so remove loop over possibly multiple entries in one block.
We should eventually migrate llvm::support::endianness to std::endian
when C++20 is available for the codebase.
This patch prepares our codebase for that future by removing the
assumption that native is a unique value different from both big and
little. Note that in C++20, native is equal to either big or little
on typical machines, where the endianness is the same for all scalar
types.
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 db51e57289, which was reverted in 05b1a2cb3e 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.
