When trying to perf inject JIT dump generatd through the perf plugin,
perf fails with the following error:
```
jitdump file contains invalid or unsupported flags 0xf5880666c26c
0x2b750 [0xa8]: failed to process type: 10 [Operation not permitted]
```
It turns out that Header's Flags field was never initialized, so the
value could be random.
This patch fixes the issue by initialising all Header's fields.
Co-authored-by: Lang Hames <lhames@gmail.com>
The CMake ADDITIONAL_HEADER_DIRS directive for two Orc libraries,
specifically Shared and TargetProcess, used incorrect values that
pointed to its parent library include directory instead of its own. This
is now fixed.
- Replace getLibraries() with cursor-based iteration.
- Simplify search logic and handle new libraries during scanning.
- Make symbol resolution faster with single enumeration and early exit.
Updates ExecutionSession::runJITDispatchHandler to take the argument
buffer for the function as a WrapperFunctionBuffer, rather than an
ArrayRef<char>.
This is a first step towards more efficient jit-dispatch handler calls:
1. Handlers can now be run as tasks, since they own their argument
buffer (so there's no risk of it being deallocated before they're run)
2. In in-process JIT setups, this will allow argument buffers to be
passed in directly from the ORC runtime, rather than having to copy the
buffer.
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).
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.
- 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.
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.
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.
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.
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.
This commit adds operations to orc::MemoryAccess for reading basic types
(uint8_t, uint16_t, uint32_t, uint64_t, pointers, buffers, and strings)
from executor memory.
The InProcessMemoryAccess and EPCGenericMemoryAccess implementations are
updated to support the new operations.
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm/ExecutionEngine`
library. These annotations currently have no meaningful impact on the
LLVM build; however, they are a prerequisite to support an LLVM Windows
DLL (shared library) build.
## Background
This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
The bulk of these changes were generated automatically using the
[Interface Definition Scanner (IDS)](https://github.com/compnerd/ids)
tool, followed formatting with `git clang-format`.
The following manual adjustments were also applied after running IDS on
Linux:
- Add `LLVM_ABI_FRIEND` to friend member functions declared with
`LLVM_ABI`
- Add `LLVM_ABI` to a subset of private class methods and fields that
require export
- Add `LLVM_ABI` to a small number of symbols that require export but
are not declared in headers
- Add `LLVM_ABI` to a number of `extern "C"` methods that IDS missed
because they're implicitly exported
## Validation
Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:
- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang
Part of ongoing work to make core ORC operations asynchronous.
This only affects the runner utilities, not the AllocationActions themselves.
The AllocationActions will be made asynchronous in a future patch.
The find-dynamic-unwind-info callback registration APIs in libunwind
limit the number of callbacks that can be registered. If we use multiple
UnwindInfoManager instances, each with their own own callback function
(as was the case prior to this patch) we can quickly exceed this limit
(see https://github.com/llvm/llvm-project/issues/126611).
This patch updates the UnwindInfoManager class to use a singleton
pattern, with the single instance shared between all LLVM JITs in the
process.
This change does _not_ apply to compact unwind info registered through
the ORC runtime (which currently installs its own callbacks).
As a bonus this change eliminates the need to load an IR "bouncer"
module to supply the unique callback for each instance, so support for
compact-unwind can be extended to the llvm-jitlink tools (which does not
support adding IR).
The system libunwind on older Darwins does not support JIT registration of
compact-unwind. Since the CompactUnwindManager utility discards redundant
eh-frame FDEs by default we need to remove the compact-unwind section first
when targeting older libunwinds in order to preserve eh-frames.
While LLJIT was already doing this as of eae6d6d18bd, MachOPlatform was not.
This was causing buildbot failures in the ORC runtime (e.g. in
https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA/3479/).
This patch updates both LLJIT and MachOPlatform to check a bootstrap value,
"darwin-use-ehframes-only", to determine whether to forcibly preserve
eh-frame sections. If this value is present and set to true then compact-unwind
sections will be discarded, causing eh-frames to be preserved. If the value is
absent or set to false then compact-unwind will be used and redundant FDEs in
eh-frames discarded (FDEs that are needed by the compact-unwind section are
always preserved).
rdar://143895614
Re-enables compact-unwind support in JITLink, which was reverted in b04847b427d
due to buildbot failures.
The underlying cause for the failures on the buildbots was the lack of
compact-unwind registration support on older Darwin OSes. Since the
CompactUnwindManager pass now removes eh-frames by default we were left with
unwind-info that could not be registered. On x86-64, where eh-frame info is
produced by default the solution is to fall back to using eh-frames. On arm64
we simply can't support exceptions on older OSes.
This patch updates the EHFrameRegistrationPlugin to remove the compact-unwind
section (__LD,__compact_unwind) when installed, forcing use of eh-frames when
the EHFrameRegistrationPlugin is used. In LLJIT, the EHFrameRegistrationPlugin
continues to be used for all non-Darwin platform, and will be added on Darwin
platforms when the a CompactUnwindRegistrationPlugin instance can't be created
(e.g. due to missing support for compact-unwind info registration).
The lit.cfg.py script is updated to check whether the host OSes default unwind
info supports JIT registration, allowing tests to be disabled for older Darwin
OSes on arm64.
This reverts commit d6524c8dfa37634257050ca71d16e117b802181c. This
reverts commit b1bd73700a1fb6f450e0f6f9c405a9c8bde2cae7.
This was causing bot failures on Darwin
https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-cmake-RA-incremental/7315/
Clang.Interpreter.simple-exception.cpp
Clang-Unit.Interpreter/ExceptionTests/_/ClangReplInterpreterExceptionTests/0.1
LLVM.ExecutionEngine/OrcLazy.minimal-throw-catch.ll
https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA/3415/
ORC-x86_64-darwin.TestCases/Darwin/Generic.exceptions.cpp
ORC-x86_64-darwin.TestCases/Darwin/x86-64.lljit-ehframe.cpp
This reapplies 4f0325873fa (and follow up patches 26fc07d5d88, a001cc0e6cdc,
c9bc242e387, and fd174f0ff3e), which were reverted in 212cdc9a377 to
investigate bot failures (e.g.
https://lab.llvm.org/buildbot/#/builders/108/builds/8502)
The fix to address the bot failures was landed in d0052ebbe2e. This patch also
restricts construction of the UnwindInfoManager object to Apple platforms (as
it won't be used on other platforms).
This reverts 4f0325873faccfbe171bae4babceb65975ca892e and follow-up patches
(see below) while I investigate some ongoing failures on the buildbots.
---
Revert "[clang-repl] Try to XFAIL testcase on arm32 without affecting arm64
darwin."
This reverts commit fd174f0ff3e793fe96a6663b1488ed159cfe042f.
Revert "[clang-repl] The simple-exception test now passes on arm64-darwin."
This reverts commit c9bc242e387f4a4a3dfcd86561f3ec0ca8a72d62.
Revert "[ORC] Destroy defunct MaterializationUnits outside the session lock."
This reverts commit a001cc0e6cdcfa672b8aff9ce6d14782bb96356a.
Revert "[ORC] Add explicit narrowing casts to fix build errors."
This reverts commit 26fc07d5d88760ad659599184fd10181287d2d9e.
Revert "[ORC] Enable JIT support for the compact-unwind frame info format on
Darwin."
This reverts commit 4f0325873faccfbe171bae4babceb65975ca892e.
For Darwin/arm64 (including Apple Silicon Macs) this will enable exception
handling and stack unwinding in JIT'd code.
Darwin supports two unwind-info formats: DWARF eh-frames and compact-unwind. On
Darwin/x86-64 compilers usually produce both by default, and ORC supported
exceptions and unwinding via eh-frames (same as on Linux), discarding the
redundant compact-unwind info. On Darwin/arm64 compilers typically default to
producing compact-unwind only, with DWARF eh-frames as a fallback for functions
that can't be described in compact-unwind. Since ORC did not previously support
the compact-unwind format and eh-frames were not present ORC was unable to
handle exceptions or unwinding by default in Darwin/arm64 JIT'd code.
This patch enables support for the compact-unwind-info format, and contains
three major moving parts:
(1) The JITLink CompactUnwindManager class is responsible for transforming the
__compact_unwind records produced by the linker into the __unwind_info
tables that libunwind parses during unwinding. To enable this the
CompactUnwindManager class provides three JITLink passes: The
prepareForPrune pass that splits the __compact_unwind section into
single-record blocks, allowing unused records to be dead-stripped; the
processAndReserveUnwindInfo pass that reserves space for the final
__unwind_info section, and the writeUnwindInfo pass that writes the
__unwind_info section.
(2) The OrcTargetProcess UnwindInfoManager class maintains a table of
registered JIT'd __unwind_info and __eh_frame sections, and handles
requests from libunwind for unwind info sections (by registering a callback
with libunwind's __unw_add_find_dynamic_unwind_sections function).
(3) The Orc UnwindInfoRegistrationPlugin, which scans LinkGraphs for
__unwind_info and __eh_frame sections to register with the
UnwindInfoManager.
This commit adds the CompactUnwindManager passes to the default JITLink
pipelines for Darwin/arm64 and Darwin/x86-64, and UnwindInfoManager intances to
the SelfExecutorProcessControl class (when built for apple platforms) and the
llvm-jitlink-executor tool.
The LLJIT class will now create an UnwindInfoRegistrationPlugin when targeting
a process running on Darwin if it detects that an UnwindInfoManager is
available to handle the registrations.
The ORC runtime macho_platform class already supported libunwind callbacks, so
out-of-process execution and unwinding support will work when loading the ORC
runtime.
The llvm-jitlink tool will only support compact-unwind when the orc-runtime is
loaded, as the UnwindInfoRegistrationPlugin requires access to an IR compiler
to load a helper module and llvm-jitlink does not provide an IR compiler.
Make EPCGenericMemoryAccess the default implementation for the MemoryAccess
object in SimpleRemoteEPC, and add support for the WritePointers operation to
OrcTargetProcess (previously this operation was unimplemented and would have
triggered an error if accessed in a remote-JIT setup).
No testcase yet: This functionality requires cross-process JITing to test (or a
much more elaborate unit-test setup). It can be tested once the new top-level
ORC runtime project lands.
Use LLVM_ALWAYS_EXPORT for __jit_debug_descriptor and
__jit_debug_register_code so there exported even if LLVM is not built as
a shared library.
This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on
windows #109483.
