Implements `reserveAllocationSpace` and provides an option to enable
`needsToReserveAllocationSpace` for large-memory environments with
AArch64.
The [AArch64
ABI](https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst#7code-models)
has restrictions on the distance between TEXT and GOT sections as the
instructions to reference them are limited to 2 or 4GB. Allocating
sections in multiple blocks can result in distances greater than that on
systems with lots of memory. In those environments several projects
using SectionMemoryManager with MCJIT have run across assertion failures
for the R_AARCH64_ADR_PREL_PG_HI21 instruction as it attempts to address
across distances greater than 2GB (an int32).
Fixes#71963 by allocating all sections in a single contiguous memory
allocation, limiting the distance required for instruction offsets
similar to how pre-compiled binaries would be loaded into memory.
Co-authored-by: Lang Hames <lhames@gmail.com>
Also renames CWrapperFunctionResult to CWrapperFunctionBuffer.
These types are used as argument buffers, as well as result buffers. The
new name better reflects their purpose, and is consistent with naming in
the new ORC runtime (llvm-project/orc-rt).
On ppc64le some sections like .toc get merged into other sections by
JITLink. As such, some sections in the object file may not be present in
the link graph. Skip those sections.
The WrapperFunctionBuffer(CWrapperFunctionBuffer) constructor takes
ownership of the underlying buffer (if one exists). Making the
constructor explicit makes this clearer at the call site.
In 4 years the ELF debugger support plugin wasn't adapted to other
object formats or debugging approaches. After the renaming NFC in
https://github.com/llvm/llvm-project/pull/168343, this patch tailors the
plugin to ELF and section load-address patching. It allows removal of
abstractions and consolidate processing steps with the newly enabled
AllocActions from https://github.com/llvm/llvm-project/pull/168343.
The key change is to process debug sections in one place in a
post-allocation pass. Since we can handle the endianness of the ELF file
the single `visitSectionLoadAddresses()` visitor function now, we don't
need to track debug objects and sections in template classes anymore. We
keep using the `DebugObject` class and drop `DebugObjectSection`,
`ELFDebugObjectSection<ELFT>` and `ELFDebugObject`.
Furthermore, we now use the allocation's working memory for load-address
fixups directly. We can drop the `WritableMemoryBuffer` from the debug
object and most of the `finalizeWorkingMemory()` step, which saves one
copy of the entire debug object buffer. Inlining `finalizeAsync()` into
the pre-fixup pass simplifies quite some logic.
The original patch broke compiler-rt checks: db5eeddbd3
Reverted with: 0182a76970
Allow C programs to use JITLink with trivial new C-API wrapper. Modeled
on `LLVMOrcCreateRTDyldObjectLinkingLayerWithSectionMemoryManager`
except that it has to deal with failure of
`jitlink::InProcessMemoryManager::Create()`. Function name suggested by
@lhames in https://github.com/llvm/llvm-project/issues/106203.
I suppose failure of underlying platform-specific things like
`sysconf(_SC_PAGESIZE)` shouldn't really happen. An alternative error
reporting style might be to follow
`LLVMOrcCreateDynamicLibrarySearchGeneratorForProcess` and return
`LLVMErrorRef` with an output parameter for the `LLVMOrcObjectLayerRef`,
but then it wouldn't be a drop-in replacement for
`LLVMOrcCreateRTDyldObjectLinkingLayerWithSectionMemoryManager`.
Thoughts?
This is wanted by PostgreSQL (branch using this API:
https://github.com/macdice/postgres/tree/llvm-22-proposed-c-api). (We're
also using `LLVMCreatePerfJITEventListener`,
`LLVMCreatePerfJITEventListener`,
`LLVMOrcRTDyldObjectLinkingLayerRegisterJITEventListener`, so it looks
like we'll need to research `PerfSupportPlugin`,
`DebuggerSupportPlugin`, `ObjectLinkingLayer::addPlugin()`...)
In 4 years the ELF debugger support plugin wasn't adapted to other
object formats or debugging approaches. After the renaming NFC in
https://github.com/llvm/llvm-project/pull/168343, this patch tailors the
plugin to ELF and section load-address patching. It allows removal of
abstractions and consolidate processing steps with the newly enabled
AllocActions from https://github.com/llvm/llvm-project/pull/168343.
The key change is to process debug sections in one place in a
post-allocation pass. Since we can handle the endianness of the ELF file
the single `visitSectionLoadAddresses()` visitor function now, we don't
need to track debug objects and sections in template classes anymore. We
keep using the `DebugObject` class and drop `DebugObjectSection`,
`ELFDebugObjectSection<ELFT>` and `ELFDebugObject`.
Furthermore, we now use the allocation's working memory for load-address
fixups directly. We can drop the `WritableMemoryBuffer` from the debug
object and most of the `finalizeWorkingMemory()` step, which saves one
copy of the entire debug object buffer. Inlining `finalizeAsync()` into
the pre-fixup pass simplifies quite some logic.
We still track `RegisteredObjs` here, because we want to free memory
once the corresponding code is freed. There will be a follow-up patch
that turns it into a dealloc action.
In 4 years the plugin wasn't adapted to other object formats. This patch
makes it specific for ELF, which will allow to remove some abstractions
down the line. It also moves the plugin from LLVMOrcJIT into
LLVMOrcDebugging, which didn't exist back then.
When scanning an interface source (dylib or TBD file), consider
"fallback" architectures (CPUType / CPUSubType pairs) in addition to the
process's CPUType / CPUSubType.
Background:
When dyld loads a dylib into a process it may load dylib or slice whose
CPU type / subtype isn't an exact match for the process's CPU type /
subtype. E.g. arm64 processes can load arm64e dylibs / slices.
When building an interface we need to follow the same logic, otherwise
we risk generating a spurious "does not contain a compatible slice"
error. E.g. If we're running an arm64 JIT'd program and loading an
interface from a TBD file, and if no arm64 slice is present in that
file, then we should fall back to looking for an arm64e slice.
rdar://164510783
These APIs are MachO specific, and the interfaces are about to be
extended to support more MachO-specific behavior. For now it makes sense
to group them with other MachO specific APIs in MachO.h.
The `DebugObjectManagerPlugin` implements debugger support for ELF
platforms with the GDB JIT Interface. It emits a separate debug object
allocation in addition to the LinkGraph's own allocation. This used to
happen in the plugin's `notifyEmitted()` callback, i.e. after the
LinkGraph's allocation was finalized. In the meantime, it had to block
finalization of the corresponding materialization unit to make sure that
the debugger can register the object before the code runs.
This patch switches the plugin to use an allocation action instead. We
can remove the `notifyEmitted()` hook and implement all steps as JITLink
passes.
Set up initial infrastructure for SystemZ architecture support in
JITLink. It includes features like GOT and PLT handling. Relaxation of
GOT/PLT and support for TLS were intentionally left out for the moment.
Support for TLS might require info regarding moduleID. This could
further mean changes to target independent part of JITLink and library
support.
---------
Co-authored-by: anoopkg6 <anoopkg6@github.com>
- Fixed architecture compatibility check.
Previously, we used `sys::getDefaultTriple()`, which caused issues on
build bots
using cross-compilation. We now ensure that the target architecture
where the
shared library (.so) is run or loaded matches the architecture it was
built for.
- Fixed ensureFilterBuilt assertion failure.
- Replaced use of FilteredView with a safer alternative for concurrent
environments.
The old FilteredView approach iterated over shared state without
sufficient
synchronization, which could lead to invalid accesses when libraries
were being
added or removed concurrently.
This PR reapplies the changes previously introduced in
https://github.com/llvm/llvm-project/pull/148410.
It introduces a redesigned and rebuilt Cling-based auto-loading
workaround that enables scanning libraries and resolving unresolved
symbols within those libraries.
Fix build failures in LibraryResolverTest and silence symlink warning
This commit resolves issues observed in the build bots:
1. Silences the -Wunused-result warning by handling the return value
of ::symlink in LibraryResolverTest.cpp. Previously, ignoring
the return value triggered compiler warnings.
2. Fixes a linker error in OrcJITTests caused by an undefined
symbol: llvm::yaml::convertYAML. The test setup in
LibraryResolverTest.cpp now correctly links against the required
LLVM YAML library symbols.
3. Fixes persistent build bot failure caused by a path difference issue.
This resolves the build failures for PR
https://github.com/llvm/llvm-project/pull/148410 on the affected bots.
After #164340 there is a tsan race on `OutstandingSymbolsCount` when
decrementing it in `notifySymbolMetRequiredState` vs reading it in
`isComplete()`. Fix this by having `IL_emit` filter out non-completed
queries when it has the lock to do so, and that way we avoid needing to
call `isComplete()` later.
This PR reapplies the changes previously introduced in #148410.
It introduces a redesigned and rebuilt Cling-based auto-loading
workaround that enables scanning libraries and resolving unresolved
symbols within those libraries.
…fixes.
This reapplies c8c86efbbb5, which was reverted in 13ca8723d1b due to bot
failures. Those failures were compilation errors exposed when LLVM is
built with LLVM_ENABLE_EXPENSIVE_CHECKS=On. They have been fixed in this
commit.
WaitingOnGraph tracks waiting-on relationships between nodes (intended
to represent symbols in an ORC program) in order to identify nodes that
are *Ready* (i.e. are not waiting on any other nodes) or have *Failed*
(are waiting on some node that cannot be produced).
WaitingOnGraph replaces ORC's baked-in data structures that were
tracking the same information (EmissionDepUnit, EmissionDepUnitInfo,
...). Isolating this information in a separate data structure simplifies
the code, allows us to unit test it, and simplifies performance testing.
The WaitingOnGraph uses several techniques to improve performance
relative to the old data structures, including symbol coalescing
("SuperNodes") and symbol keys that don't perform unnecessary reference
counting (NonOwningSymbolStringPtr).
This commit includes unit tests for common dependence-tracking issues
that have led to ORC bugs in the past.
This PR introduces a redesigned and rebuilt Cling-based auto-loading
workaround, which enables scanning libraries and searching for
unresolved symbols within the scanned libraries.
SimpleRemoteMemoryMapper is a MemoryMapper implementation that manages
remote memory via EPC-calls to reserve, initialize, deinitialize, and
release operations. It is compatible with the
SimpleExecutorMemoryManager backend, and its introduction allows
MapperJITLinkMemoryManager to use this backend.
It is also intended to be compatible with the
orc_rt::SimpleNativeMemoryMap backend.
Teach ExecutorSimpleMemoryManager to handle slab reserve/release
operations, plus separate initialize/deinitialize for regions within the
slab. The release operation automatically deinitializes any regions
within each slab that have not already been released.
EPCGenericJITLinkMemoryManager is updated to use the reserve (allocate),
initialize (finalize), and relesae (deallocate) operations.
This brings ExecutorSimpleMemoryManager into alignment with the
orc_rt::SimpleNativeMemoryMap class, allowing SimpleNativeMemoryMap to
be used as a backend for EPCGenericJITLinkMemoryManager.
A future commit will introduce a new MemoryMapper class that will make
SimpleNativeMemoryMap usable as a backend for
MapperJITLinkMemoryManager.
This work will make it easier to re-use in-tree APIs and tools with the
new ORC runtime.
This reverts commit 3b5842c9c41a441280100045ef62bb8a0fe7200f.
The intent of the original commit was to begin enabling asynchronous
alloation actions (calls attached to JIT'd memory initialization and
deinitialization). The asynchronous allocation actions scheme was
fleshed-out in a development branch, but ran into an issue: Functions
implementing actions are allowed to live in JIT'd code (e.g. in the ORC
runtime), but we can't genally rely on tail-call elimination kicking in.
This resulting in dealloc actions returning via stack frames that had
been deallocated, triggering segfaults.
It's possible that there are other approaches that would allow
asynchronous allocation actions to work, but they're not on the critical
path for JIT improvements so for now we'll just revert.
With the help of @lhames, This pull request introduces the dlupdate
function in the ORC runtime. dlupdate enables incremental execution of
new initializers introduced in the REPL environment. Unlike traditional
dlopen, which manages initializers, code mapping, and library reference
counts, dlupdate focuses exclusively on running new initializers.
This patch adds the new **executor-side resolver API** as suggested by
@lhames. It introduces a `DylibSymbolResolver` that helps resolve
symbols for each loaded dylib.
Previously, we returned a `DylibHandle` to the controller. Now, we wrap
the native handle inside `DylibSymbolResolver` and return a
`ResolverHandle` instead. This makes the code cleaner and separates the
symbol resolution logic from raw handle management.
Adds the name and triple of the graph to LinkGraph::dump output before
the rest of the graph content. Calls from JITLinkGeneric.cpp to dump the
graph are updated to avoid redundantly naming the graph.
