On Wasm, it's not currently possibly to change which `personality` is
attached to a given IR function. This is primarily because no matter
what `personality` is attached, codegen creates a call to a
`Unwind_CallPersonality` wrapper hard-coded to call c++abi's
personality.
In order to allow alternative personalities without introducing bloat at
each personality call site, this PR adjusts the ABI of the personality
on Wasm. `Unwind_CallPersonality` is moved to `libcxxabi` under the name
`__gxx_wasm_personality_v0`, with the "real" personality code renamed
`__gxx_personality_imp` and called by `__gxx_wasm_personality_v0` (after
resetting the landing pad context).
The signature of EH personalities on Wasm is now `int personality(void*
exception_object)` (where the int return is `_Unwind_Reason_Code` and
the `void*` is `_Unwind_Exception*`), and personalities are expected to
`__wasm_lpad_context.selector = 0;`.
Based on #175202
This is the first of two independent fixes for libunwind on ppc64le
(ELFv2 ABI, little-endian), where two separate bugs together cause
SIGSEGV during backtracing. This commit addresses the VSX register
corruption; the TOC-restore fault is handled in a follow-up. Both
were discovered while debugging lang/rust build failures with
RUST_BACKTRACE=1 on FreeBSD/powerpc64le (IBM POWER9).
On ppc64le, `unw_getcontext` saves each VS register with an in-place
`xxswapd n, n` followed by `stxvd2x`. The swap is needed because
`stxvd2x` stores doublewords in the wrong order on LE. However, the
macro never applies a second `xxswapd` to restore the register after
the store, so all 64 VS registers are permanently corrupted on return
from `unw_getcontext`.
This affects every callee-saved VSX register: f14-f31 (VSR14-VSR31)
and VR20-VR31 (VSR52-VSR63). After `_Unwind_Backtrace` returns, any
code that uses these registers sees wrong values. In practice this
manifests as SIGSEGV inside hashbrown's `reserve_rehash`: VR20-VR31
are corrupted before a SIMD comparison loop runs, producing an
out-of-bounds access.
Fix: add a second `xxswapd n, n` after the `stxvd2x` store. Since
`xxswapd` is its own inverse, the pair is a no-op on the architectural
register while still writing the correctly byte-swapped value to memory.
Under PAuth_LR, compact unwind entries marked UNWIND_ARM64_MODE_FRAME_PAUTH_LR are signed with the PC of the pacibsppc at the start of the range. The compiler may emit those entries with UNWIND_IS_NOT_FUNCTION_START when the pacibsppc is not the first instruction in the function; the unwinder must scan backwards past such entries to find the actual function start (and its LSDA pointer).
When unwinding a PAuth_LR frame, authenticate and re-sign using setIPPAuthLR(), which calls __builtin_ptrauth_auth_with_pc_and_resign when available, falling back to inline asm (autib171615 + pacib) for compilers that lack the builtin.
To reduce the size of Compact Unwind entries for shrinkwrapped frames, new offset bits encode the distance in multiples of 4 bytes from the range start to the pacibsppc. The compiler emits paired FRAMELESS/FRAMELESS+PAUTH_LR entries that the linker merges into a single FRAME_PAUTH_LR | (offset/4) << 12 encoding.
rdar://161907302&169746432&171118419
This new CFI directive directly assigns an RA signing state to the RA_SIGN_STATE DWARF pseudo-register for use when unwinding, to indicate whether the value of PC has been used as a diversifier for return address signing. The new directive subsumes and replaces .cfi_negate_ra_state_with_pc, which was found to be unsuitable for descibing some block layouts [1], particularly in hot-cold-split functions.
1: https://github.com/ARM-software/abi-aa/pull/346
Further to https://github.com/llvm/llvm-project/pull/209306, test a case
where a signal handler is a Virtual API function triggered synchronously
while the VAPI is not active. Resuming an ancestor context of the signal
frame should call the VAPI return glue.
---------
Assisted-by: IBM Bob
Test detection, during stepping, of the backchain mutation introduced by
a VAPI call (see https://github.com/llvm/llvm-project/pull/209280).
Further, test resumption of contexts using cursors obtained while a VAPI
is active on the thread.
Testing is done via FileCheck inspection of trace output enabled by
`LIBUNWIND_PRINT_UNWINDING=1`. When Live Library Update is not enabled,
synthetic trace output is generated by the test program itself.
---------
Assisted-by: IBM Bob
In AIX's implementation of LLU (Live Library Update), the caller of a
Virtual API (VAPI) interface instead calls VAPI glue and the
implementation for a VAPI function is entered from the VAPI glue. If a
VAPI is not already active on the thread, the VAPI calls the
implementation of the VAPI function with the link register (LR) value
set to a return address in the VAPI glue. In this case, the LR (return
address) value on entry to the VAPI glue is saved in the VAPI control
block. This PR checks whether the return address in a stack frame falls
within the VAPI address range. If it does, the unwinder retrieves the LR
value from the VAPI control block and uses it as the return address
during stack unwinding. In addition, before transferring control to a
landing pad, this PR executes the VAPI return glue to clear the VAPI
control block if the VAPI glue was used.
---------
Co-authored-by: Hubert Tong <hubert.reinterpretcast@gmail.com>
The pseudo register was previously hacked in under kRegisterIsUndefined, leaving it in a state that was only accessible from within the unwinder itself.
To fix this, allowing external access to the state (and therefore tests!), we invent a new register location kRegisterIsPseudo to record the additional state that the register has been defined by a .cfi_negate_ra_state opcode having been executed.
Under the LFI target the SVE `za` are not currently supported, and
neither is the `stg` instruction. When included in an LFI program they
cause verification failures due to being unsupported instructions. This
patch omits them from compilation when targeting LFI.
Tracking issue: #201242
See the [migration guide] for more information.
[migration guide]:
https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines
This is a stacked PR based on #210208, which is the standalone rename
commit for this miscellaneous Markdown migration batch.
This was prepared with rst2myst plus LLM-assisted cleanup. LLDB man
pages are intentionally left as reStructuredText because LLDB man-page
building should not take on Markdown parser dependencies.
Unfortunately, many of these miscellaneous docs do not have working
standalone doc build targets, so I was not able to render HTML for all
of them. I think the scope is small enough that this is reviewable by
hand.
The Hexagon save and restore routines dropped GPRs, producing an
incomplete context.
UnwindRegistersSave.S (__unw_getcontext): save r0-r7 (stores began at
__r[8]), drop a dead "r1 = memw(r30)" before the PC store, and return
UNW_ESUCCESS instead of a stale non-zero value.
UnwindRegistersRestore.S (jumpto): restore the missing r2-r7 (r0/r1 and
r8-r31 were already handled), and fix the stale "pointer is in r2"
comment (it is r0).
Signed-off-by: Kushal Pal <kushpal@qti.qualcomm.com>
Glibc provides the alloca function as a part of stdlib.h when
_GNU_SOURCE is declared (which is the case with standard linux builds).
[1]
On non-glibc systems, this may not be the case (for example, picolibc).
These libraries may not implicitly include alloca.h as a part of the
standard lib.
[1]
04e750e75b/stdlib/stdlib.h (L728)
Signed-off-by: Shreeyash Pandey <shrpand@qti.qualcomm.com>
The RA_SIGN_STATE pseudo register is a three-state enum, so it should be
encoded as one in the unwinder's representation. This fixes a bug on the
authentication path, which assumed "is signed with PC" was a subset of
"is signed".
Re-indent the shared library target blocks that were wrapped in
if(<runtime>_SUPPORTS_SHARED_LIBRARY) in the previous commit. This is a
whitespace-only change split out from the functional change to keep that
diff minimal and reviewable.
Co-authored-by: Claude (Opus 4.8) <noreply@anthropic.com>
On platforms that don't support shared libraries (e.g. CMAKE_SYSTEM_NAME
of "Generic", used for GPU and other baremetal targets), CMake's
Platform/Generic.cmake sets the global TARGET_SUPPORTS_SHARED_LIBS
property to FALSE. Under CMP0164's OLD behavior (the default, since the runtimes
set cmake_minimum_required(3.20)), CMake silently demotes SHARED library
targets to STATIC archives. libcxx, libcxxabi and libunwind always create their
shared target, so after demotion both the shared and static targets emit e.g.
"libc++abi.a" and Ninja fails with "multiple rules generate ...".
Rather than papering over the collision with a distinct output name,
skip creating the shared library targets entirely when the platform does not
support them, gating on the TARGET_SUPPORTS_SHARED_LIBS property (left
undefined on platforms that do support shared libraries). The few consumers of
the shared targets are guarded with TARGET checks so they fall back to the static
library or are skipped.
Also set policy CMP0164 to NEW so that any future unguarded
add_library(... SHARED ...) on an unsupported platform fails at
configure time instead of silently producing a colliding static archive.
See https://gitlab.kitware.com/cmake/cmake/-/issues/25759.
The bodies of the newly-conditional blocks are left at their original
indentation to keep this diff minimal. A follow-up commit will fix the
indentation. This was mostly AI generated with some comment fixups.
Co-authored-by: Claude (Opus 4.8) <noreply@anthropic.com>
llvm-project is home to many sphinx documentation sites, each with
configuration quirks and bespoke extensions.
The sphinx config model makes sharing code somewhat difficult. There
are options like sphinx-multiproject, but some of our docs builds are
out of the source tree while some are done out of the binary tree, so
the multiproject configuration itself would need to be generated. It
also would impose more uniformity around extensions than required.
This change instead creates a python package at utils/docs/llvm_sphinx
and makes it available to all sphinx-build processes via PYTHONPATH.
Each conf.py does not modify its own sys.path because not all builds are
out of the source tree, so there isn't a stable relative path to use to
refer to the utils/docs/ directory.
Type checking via pyright in new package is pinned to being python 3.8
compatible.
The myst slug script from llvm/docs is promoted to be the default,
with a slight edit to targets needed in FlangDriver.md to adapt to the
change.
The ghlinks extension from clang gets lifted to be the first generic
extension, although it is still only used in clang currently. I used it
as an example of a general extension that might be useful for other
projects, but I also intend to add a new generic extension in a future
patch.
As part of the move ghlinks is refactored a bit:
* Rather than have a main function directly to run its tests, those
tests are now run via the command-line entrypoint to the new package,
e.g. `python utils/docs --test` will now replace
`python clang/docs/ghlinks.py --test`. This makes the command-line
more pithy (`python utils/docs/llvm_sphinx/ext/ghlinks --test` is a
bit long), and makes the default behavior when running be to
include utils/docs in the sys.path, so imports can be absolute and
the behavior is as close to the CMake targets as possible.
* The static files that were previously written to a tempdir during
testing are just committed directly in git. The assumption here is
that the original version was taking pains to avoid polluting the
clang/docs directory with test files that would confuse sphinx-build,
and without that limitation the workaround can be removed.
* Some typing-related changes to make it strictly python 3.8 compatible.
Change-Id: Ie16de273f74973f163dbf7fe9d22d80a466d051f
The Arm DWARF spec defines UNW_AARCH64_RA_SIGN_STATE as being zeroed
until the first .cfi_negate_ra_state / .cfi_set_ra_state [1]. The GPRs
struct containing __ra_sign_state is memcpy'd directly from the
unw_context_t, which in turn is initialized by __unw_getcontext. Since
it is a pseudo register, there is no corresponding state to restore in
__unw_resume.
https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst#44call-frame-instructions
Fixes libunwind compiler diagnostic when building with clang after
034d4dcad6:
```
In file included from libunwind/src/libunwind.cpp:31:
In file included from libunwind/src/UnwindCursor.hpp:52:
libunwind/src/CompactUnwinder.hpp:339:46: error: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Werror,-Wformat]
338 | "function starting at 0x%llX",
| ~~~~
| %lX
339 | compactEncoding, functionStart);
| ^~~~~~~~~~~~~
libunwind/src/config.h:215:63: note: expanded from macro '_LIBUNWIND_DEBUG_LOG'
215 | #define _LIBUNWIND_DEBUG_LOG(msg, ...) _LIBUNWIND_LOG(msg, __VA_ARGS__)
| ~~~ ^~~~~~~~~~~
libunwind/src/config.h:181:45: note: expanded from macro '_LIBUNWIND_LOG'
181 | fprintf(stderr, "libunwind: " msg "\n", __VA_ARGS__); \
| ~~~ ^~~~~~~~~~~
In file included from libunwind/src/libunwind.cpp:31:
In file included from libunwind/src/UnwindCursor.hpp:52:
libunwind/src/CompactUnwinder.hpp:458:39: error: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Werror,-Wformat]
457 | "function starting at 0x%llX",
| ~~~~
| %lX
458 | encoding, functionStart);
| ^~~~~~~~~~~~~
libunwind/src/config.h:215:63: note: expanded from macro '_LIBUNWIND_DEBUG_LOG'
215 | #define _LIBUNWIND_DEBUG_LOG(msg, ...) _LIBUNWIND_LOG(msg, __VA_ARGS__)
| ~~~ ^~~~~~~~~~~
libunwind/src/config.h:181:45: note: expanded from macro '_LIBUNWIND_LOG'
181 | fprintf(stderr, "libunwind: " msg "\n", __VA_ARGS__); \
| ~~~ ^~~~~~~~~~~
```
The registers `x25`, `x26`, `x27`, and `x28` are reserved for the
`aarch64_lfi` target and should not be written/used. See
`llvm/docs/LFI.rst` for more details. They contain fixed constants or
temporaries used as part of assembly-level rewrites of load/store
instructions. The rewriter will reject programs that attempt to write to
these registers. It is technically OK to save/read them (in
`UnwindRegistersSave.S`), but there is no point since there is no need
to restore them (and to maintain LFI's security invariant, they in fact
cannot be written).
Introduce common infrastructure for runtimes that determines compiler
resource path locations. These variables introduced are:
* RUNTIMES_OUTPUT_RESOURCE_DIR
* RUNTIMES_INSTALL_RESOURCE_PATH
That contain the location for the compiler resource path (typically
`lib/clang/<version>`) in the build tree and the install tree (the
latter relative to CMAKE_INSTALL_PREFIX).
Additionally, define
* RUNTIMES_OUTPUT_RESOURCE_LIB_DIR
* RUNTIMES_INSTALL_RESOURCE_LIB_PATH
as for the location of clang/flang version-locked libraries (typically
`lib${LLVM_LIBDIR_SUFFIX}/<targer-triple>`, but also depends on `APPLE`
and `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`). This code is moved from
flang-rt and initially becomes its only user.
Refactored out of #171610 as requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2687382481).
Extracted `get_runtimes_target_libdir_common` from compiler-rt as
requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2689565634).
Added TODO comments to all runtimes as requested
[here](https://github.com/llvm/llvm-project/pull/171610#issuecomment-3789598635).
It turns out making the CFI check a release mode abort causes many, if
not the majority, of JITs to fail during unwinding as they do not set up
CFI sections for their generated code. As a result any JITs that do
nominally support unwinding (and catching) through their JIT or assembly
frames trip this abort.
rdar://170862047
Introduces a macro abstraction around capturing the bounds of a
function, which many platforms handle subtly differently (Mach-O, and
ELF, for example).
Also introduce an arm64[^-]* -> aarch64 available feature, to enable
more tests that would otherwise be excluded on Apple platforms, whose
target triples tend to take the form e.g. 'arm64-apple-macosx', rather
than 'aarch64-apple-macosx'.
Third, we implement the has-sme check using the appropriate sysctl, as
getauxval is not available on Darwin platforms.
The `__cpp_exception` symbol is now defined in libunwind instead of
compiler-rt. This is moved for a few reasons, but the primary reason is
that compiler-rt is linked duplicate-ly into all shared objects meaning
that it's not suitable for define-once symbols such as
`__cpp_exception`. By moving the definition to the user of the symbol,
libunwind itself, that guarantees that the symbol should be defined
exactly once and only when appropriate. A secondary reason for this
movement is that it avoids the need to compile compiler-rt twice: once
with exception and once without, and instead the same build can be used
for both exceptions-and-not.
Reverts llvm/llvm-project#125412
See the discussion in #125412 for why this is necessary. The summary is
that:
- Eliding arguments is the C23 extension, but libunwind builds its C
files with `-std=c99`, so this change broke the build.
- `-Wno-unused-parameter` is part of the build for libunwind, so the
codebase does allow them.
On Windows, libunwind is normally only built in mingw mode; it's not
relevant for MSVC targets. (Attempting to build it is entirely blocked
in CMake, see [1]).
In mingw headers, the type EXCEPTION_DISPOSITION is defined as an int
while it is an enum in the MSVC vcruntime headers.
However, in addition to the canonical enum members, we also use a value
which has no assigned enum member. In older mingw-w64 headers, there was
a define for this value, 4, with the name ExceptionExecuteHandler, but
that was removed in [2]. The libunwind code reference this value just by
the literal value 4, with a comment referencing it as
ExceptionExecuteHandler.
This extra enum value isn't passed to the outside Microsoft runtime, but
is only used to pass values from one part of libunwind to another; this
handling is necessary for the forced_unwind{1-3}.pass.cpp tests to
succeed.
If the mingw-w64 headers would define EXCEPTION_DISPOSITION as an enum,
just like the MSVC vcruntime headers, then we'd run into build errors
and warnings like this:
llvm-project/libunwind/src/Unwind-seh.cpp:166:14: error: cannot initialize return object of type 'EXCEPTION_DISPOSITION' (aka 'enum _EXCEPTION_DISPOSITION') with an rvalue of type 'int'
166 | return 4 /* ExceptionExecuteHandler in mingw */;
| ^
llvm-project/libunwind/src/Unwind-seh.cpp:185:14: error: cannot initialize return object of type 'EXCEPTION_DISPOSITION' (aka 'enum _EXCEPTION_DISPOSITION') with an rvalue of type 'int'
185 | return 4 /* ExceptionExecuteHandler in mingw */;
| ^
llvm-project/libunwind/src/Unwind-seh.cpp:272:8: warning: case value not in enumerated type 'EXCEPTION_DISPOSITION' (aka 'enum _EXCEPTION_DISPOSITION') [-Wswitch]
272 | case 4 /*ExceptionExecuteHandler*/:
| ^
Fix these cases by adding explicit casts between EXCEPTION_DISPOSITION
and int.
A (partial) similar change was proposed in [3], but the author never
followed up on the discussion, and the PR was later closed.
[1] b0b546d447
[2] 2de6703961
[3] https://github.com/llvm/llvm-project/pull/159293
This performs most of the post-branch tasks to start working on the LLVM
23 release. Things that are left to do:
- Update the unicode version
- Update CI versions and supported compiler versions
For Apple's arm64e or Linux's pauthtest, `Registers_arm64::link_reg_t`
type is `__ptrauth`-qualified. When passing a value of such a type to a
function accepting non-`__ptrauth`-qualified parameter with `pint_t`
type, an authentication is performed. So, the corresponding callee
argument does not contain an embedded signature, making it prone to
substitution if spilled to the stack.
This patch prevents early authentication of signed values of
`link_reg_t` type by passing them as const l-value references instead of
passing by value with type `pint_t`. This way, the callee would operate
with a `__ptrauth`-qualified value containing a signature, allowing to
detect a substitution if the value is spilled to the stack.
Note that this approach was introduced previously in #143230 for some
other functions. In this patch, we apply the approach to the functions
which were not considered previously.
The PAuth-related checks performed for arm64e are also performed for
other PAuth-enabled ABIs such as Linux's pauthtest. This patch
introduces use of 'PAuth-enabled ABI' phrase instead of 'arm64e' term
for non-arm64e specific things. Also, on non-arm64e we cannot assume
that we have FPAC, so an additional explanation regarding resign
function guarantees is provided.
Note that other comments mentioning arm64e while not being
arm64e-specific are fixed as part of #171717.
Fixes#160117
This patch removes explicit dependencies on cxx_experimental for
installations that are local to the test suite. Such dependencies
are not required anymore from the test-suite installation targets
since the proper dependency is now encoded between cxx and
cxx_experimental.
This patch moves away from using cmake_install scripts to install the
various targets when building runtimes, since those have been deprecated
by CMake. Instead, we use `cmake --install` which is the prefered
method.
This patch also localizes how we set dependencies on the various
installation targets, allowing the removal of a few global variables
that were used as lists.
Finally, it makes the way we set up installation targets for libc++,
libc++abi and libunwind consistent again.
This patch adds an installation step where we install libc++ in a fake
installation tree before testing libunwind. This is necessary because
some configurations (in particular "generic-merged") require libc++ to
be installed, since the libunwind tests are actually linking libc++.so
in which libc++abi.a and libunwind.a have been merged.
Without this, we were actually failing to find `libc++.so` to link
against and then linking against whatever system library we'd find in
the provided search directories. While this happens to work in the
current CI configuration, this breaks down when updating to newer build
tools.
There might be a cleaner way to enable these tests running on FreeBSD,
I'm open to suggestions.
Co-authored-by: Alexander Richardson <mail@alexrichardson.me>
Since insns are always stored LE, on a BE system the opcodes will be
loaded byte-reversed. Therefore, define two sets of opcodes, one for LE
and one for BE.
