If there is no debug information, we wouldn't call
`DebugObject::collectTargetAlloc` in the post-allocation phase.
Therefore, when it's in the post-fixup phase,
`DebugObject::awaitTargetMem` will fail with _"std::future_error: No
associated state"_ because the std::future was not even populated.
This PR fixes
1. issue #175509 about missing support of deinitialize on ELF platform.
2. missing support of execution order by proirity at both initialize and
deinitialize stage.
cc: @tqchen @joker-eph
Updates CompactUnwindTraits_MachO_arm64 and
CompactUnwindTraits_MachO_x86_64 encodingCanBeMerged methods to use
switch statements that clearly list mergeable encodings, and have a
default "false" case.
Since the new scheme explicitly covers DWARF modes (always
non-mergeable), this patch removes the separate DWARF mode check from
mergeRecords in CompactUnwindSupport.h.
Compact unwind record merging is an optimization. Using a can-be-merged
predicate is preferrable to a "cannot-be-merged" predicate as the former
encourages conservatively correct implementations: "what is safe to
merge" is easier to reason about than "what is safe to not not merge".
Add missing spaces to error messages, use Triple::getArchName (gives
canonical arch name on Darwin, e.g. "arm64" rather than "aarch64").
No testcase for this one: the change is cosmetic, and the error message
format not relied upon anywhere.
Optimize the GOT and Stub relocations if the edge target address is in
range from call site - Indirect jump by plt stub can be replaced with
direct jump to target in post-allocation optimization.
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 stub function is generated for R_MIPS_26 relocation, which could be
used for local jumping inside a function, and do not expect any
temporary register to be clobbered.
Use AT instead of T9 for the stub function, otherwise functions using T9
will be messed up.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
…ces"
This reapplies 906b48616c03948a4df62a5a144f7108f3c455e8, which was
reverted in c11df52f9b847170b766fb71defd2a9222d95a8d due to bot
failures.
The testcase has been dropped from this recommit as it failed on several
bots (possbly due to differing backtrace formats or failure modes). I'll
re-introduce the testcase in a follow-up commit so that it cane be
iterated on (and re-reverted if necessary) without affecting the options
introduced by this commit. (Since these options are best-effort
debugging tools it's ok if they live in-tree without a test for now).
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.
This reverts commit 906b48616c03948a4df62a5a144f7108f3c455e8.
The forward fix for this got reverted in
25976e83606f1a7615e3725e6038bb53ee96c3d5, so reverting the original
commit given it is still broken and the forward fix that mitigated most
of the issues is no longer in tree.
StringMap duplicates the option name to a new allocation for every
option, which is not necessary. Instead we can use the same StringRef
that the Option already uses inside a DenseMap. This reduces the amount
of allocations when loading libLLVM.
This patch adds tools for capturing symbol information from JIT'd code
and using it to symbolicate backtraces. This is useful for debugging
crashes in JIT-compiled code where traditional symbolication tools may
not have access to the JIT symbol table. These tools are not a general
solution to the JIT symbolication problem (that will require further
integration with system components like libunwind, the dynamic linker,
and/or crash tracing tools), but will aid in JIT debugging and
development until a general solution is available.
APIs Added:
1. SymbolTableDumpPlugin - A LinkGraphLinkingLayer::Plugin that captures
symbol information as code is JIT'd and writes it to a file.
- Create(StringRef Path) ->
Expected<std::shared_ptr<SymbolTableDumpPlugin>> Creates a plugin that
appends symbol information to the specified file.
- Symbol table format: "<link graph name>" <address> <symbol name>
<address> <symbol name> ...
The plugin uses a PostAllocationPass to write symbols after addresses
have
been assigned but before the code is finalized.
2. DumpedSymbolTable - A class for symbolicating backtraces using a
previously dumped symbol table.
- Create(StringRef Path) -> Expected<DumpedSymbolTable> Loads and parses
a symbol table from a file.
- symbolicate(StringRef Backtrace) -> std::string Given text of a
backtrace, for rows ending with a hex address, adds the symbol name,
offset, and defining graph name.
New `llvm-jitlink` Command Line Options:
1. -write-symtab=<path> Enables the SymbolTableDumpPlugin to write
symbol information to the specified file as objects are JIT'd. The
symbol table can then be used to symbolicate backtraces from crashes or
signal handlers.
2. -symbolicate-with=<path> Runs llvm-jitlink in symbolication mode.
Reads the symbol table from <path> and symbolicates backtraces read from
stdin or input files.
Usage Examples:
$ llvm-jitlink -write-symtab=symbols.txt mycode.o
$ llvm-jitlink -symbolicate-with=symbols.txt - < backtrace.txt
This Error can be returned from operations on JITDylibs that cannot
proceed as the target JITDylib has been closed.
This patch uses the new error to replace an unsafe assertion in
JITDylib::define: If a JITDylib::define operation is run by an in-flight
task after the target JITDylib is closed it should error out rather than
asserting.
See also https://github.com/llvm/llvm-project/issues/174922
Allow C programs to pass a ReserveAlloc flag to the constructor of
llvm::SessionMemoryManager, using a new variant of
LLVMOrcCreateRTDyldObjectLinkingLayerWithSectionMemoryManager that has
...ReserveAlloc() appended to its name.
- 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.
fa7f7a4cab4 changed the jit-dispatch function signature used in the
orc_rt_lite_reoptimize_helper function, but jit-dispatch still takes a
raw data pointer and size argument.
Should fix the bug in
https://lab.llvm.org/buildbot/#/builders/169/builds/18319 and similar
builds.
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.
ReOptimizeLayer was building LLVM IR to define a precomputed,
SPS-serialized argument buffer, then inserting calls directly to
__orc_rt_jit_dispatch, passing the address of the precomputed buffer and
an __orc_rt_reoptimize_tag defined by the ORC runtime. This design is
non-canonical, requiring the ORC runtime to be loaded (or an extra
definition for __orc_rt_reoptimize_tag to be inserted) while not using
the runtime to perform the serialization.
This commit updates ReOptimizeLayer to instead insert calls to an
__orc_rt_reoptimize function implemented in the ORC runtime. This
function will perform serialization and call __orc_rt_jit_dispatch,
similar to other functions in the ORC runtime.
To maintain support for in-process JITs that don't use the ORC runtime,
this commit adds a ReOptimizeLayer::addOrcRTLiteSupport method which
injects IR to define __orc_rt_reoptimize (calling through to an
orc_rt_lite_reoptimize_helper function defined in LLVM) and
__orc_rt_reoptimize_tag. The ReOptimizeLayerTest is updated to use
addOrcRTLiteSupport.
If `Alloc.finalize()` fails in the post-allocation pass, we store the
error in `FinalizePromise`. If we don't reach the post-fixup pass
afterwards the error will leak. This patch adds another case in the
DebugObject destructor that will check the `Expected<T>` and report the
error.
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.
