Implementation files using the Intel syntax explicitly specify it.
Do the same for the few files using AT&T syntax.
This also enables building LLVM with `-mllvm -x86-asm-syntax=intel` in one's Clang config files
(i.e. a global preference for Intel syntax).
No functional change intended.
This hardens the unwinding logic and datastructures on systems
that support pointer authentication.
The approach taken to hardening is to harden the schemas of as many
high value fields in the myriad structs as possible, and then also
explicitly qualify local variables referencing privileged or security
critical values.
This does introduce ABI linkage between libcxx, libcxxabi, and
libunwind but those are in principle separate from the OS itself
so we've kept the schema definitions in the library specific headers
rather than ptrauth.h
See https://github.com/LuaJIT/LuaJIT/issues/593#issuecomment-1717728494
for the original explanation of the problem.
In short; when a debugger is attached, there's a
function KiUserExceptionDispatcher in the stack that is being unwound.
The function KiUserExceptionDispatcher contains a CONTEXT, with a copy
of the context from where the exception was raised. When unwinding
through this function, this whole CONTEXT gets restored.
This CONTEXT is what we receive a pointer to in the callbacks, as the
ms_ctx pointer.
When we unwind manually using RtlUnwindEx, the unwinding overwrites the
CONTEXT that is passed to it. Thus, to avoid clobbering the CONTEXT that
needs to be restored by KiUserExceptionDispatcher, we could either
declare a new temporary CONTEXT on the stack before calling RtlUnwindEx,
or just use disp->ContextRecord as we already have available.
Fixes: https://github.com/llvm/llvm-project/issues/161851
Co-authored-by: Peter Cawley <corsix@corsix.org>
Co-authored-by: Hannes Domani <ssbssa@yahoo.de>
Based on review feedback in #160026.
This makes the substitution a lot more clear now that there is no
documentation around %T.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
In the libc++ test suite, we consistently declare main() functions with
full parameters and explicitly return from the function. This helps code
that compiles the tests with -ffreestanding, where main() is not a
special function (with an implicit return and special mangling).
This patch fixes a few stray declarations, including in libunwind and
libc++abi.
Previously, we only used `objcopy`, which is not available for some
build configurations. With this patch, we not only try to use `objcopy`,
but also try to use `llvm-objcopy` if available.
This is a follow-up of https://github.com/llvm/llvm-project/pull/156383.
Our host compiler is a clang install that will default to ld if not told
otherwise.
We were telling meson to use lld, but the way that we did it was
outdated, which lead to picolib producing a linker script that lld could
not use. The tests were in fact linking with ld instead.
Using the `c_ld` setting fixes this problem. See:
https://mesonbuild.com/Machine-files.html#binaries
Then to use lld in tests we need `-fuse-ld=lld` in the config files.
Some of these options were not needed for clang 19.1.7, but were for
clang 21.1.1. We will soon update to 21.1.1 so I have included all of
the required options in this PR.
In https://github.com/llvm/llvm-project/pull/154902, the test failed
with llvm-clang-win-x-aarch64(it is a cross-build, which builds on
Windows and run on Linux, "Win to Aarch64 Linux Ubuntu Cross
Toolchain"), and objdump is not available on Windows(the build env).
Set to require x86 Linux instead.
There is an off-by-one error with current condition check for PC fallen
into the range or not. There is another check within libunwind that use
the correct checks in
5050da7ba1/libunwind/src/UnwindCursor.hpp (L2757)
```
if ((fdeInfo.pcStart <= pc) && (pc < fdeInfo.pcEnd))
```
The vector granule (AArch64 DWARF register 46) is a pseudo-register that
contains the available size in bits of SVE vector registers in the
current call frame, divided by 64. The vector granule can be used in
DWARF expressions to describe SVE/SME stack frame layouts (e.g., the
location of SVE callee-saves).
The first time VG is evaluated (if not already set), it is initialized
to the result of evaluating a "CNTD" instruction (this assumes SVE is
available).
To support SME, the value of VG can change per call frame; this is
currently handled like any other callee-save and is intended to support
the unwind information implemented in #152283. This limits how VG is
used in the CFI information of functions with "streaming-mode changes"
(mode changes that change the SVE vector length), to make the unwinder's
job easier.
A CMake change included in CMake 4.0 makes `AIX` into a variable
(similar to `APPLE`, etc.)
ff03db6657
However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to
`AIX` and `if` auto-expands variable names in CMake. That means you get
a double expansion if you write:
`if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")`
which becomes:
`if (AIX MATCHES "AIX")`
which is as if you wrote:
`if (ON MATCHES "AIX")`
You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}",
due to policy
[CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054)
which is on by default in 4.0+. Most of the LLVM CMake already does
this, but this PR fixes the remaining cases where we do not.
Needed to resolve this compilation error on some systems:
lib/libunwind/src/UnwindCursor.hpp:153:38: error: return type of
out-of-line definition of 'libunwind::DwarfFDECache::findFDE' differs
from that in the declaration
typename A::pint_t DwarfFDECache<A>::findFDE(pint_t mh, pint_t pc) {
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
lib/libunwind/src/libunwind.cpp:31:10: note: in file included from
lib/libunwind/src/libunwind.cpp:31:
#include "UnwindCursor.hpp"
^
lib/libunwind/src/UnwindCursor.hpp:100:17: note: previous declaration is
here
static pint_t findFDE(pint_t mh, pint_t pc);
~~~~~~~^
This attribute is unsupported in GCC, so far it worked because before
GCC15 did not define this macros in _CHKFEAT_GCS in arm_acle.h [1]
With gcc15 compiler libunwind's check for this macros is succeeding and
it ends up enabling 'gcs' by using function attribute, this works with
clang but not with gcc.
We can see this in rust compiler bootstrap for aarch64/musl when system
uses gcc15, it ends up with these errors
Building libunwind.a for aarch64-poky-linux-musl
```
cargo:warning=/mnt/b/yoe/master/sources/poky/build/tmp/work/cortexa57-poky-linux-musl/rust/1.85.1/rustc-1.85.1-src/src/llvm-project/libunwind/src/UnwindLevel1.c:191:1: error: arch extension 'gcs' should be prefixed by '+' cargo:warning= 191 | unwind_phase2(unw_context_t *uc, unw_cursor_t *cursor, _Unwind_Exception *exception_object) {
cargo:warning= | ^~~~~~~~~~~~~
cargo:warning=/mnt/b/yoe/master/sources/poky/build/tmp/work/cortexa57-poky-linux-musl/rust/1.85.1/rustc-1.85.1-src/src/llvm-project/libunwind/src/UnwindLevel1.c:337:22: error: arch extension 'gcs' should be prefixed by '+'
cargo:warning= 337 | _Unwind_Stop_Fn stop, void *stop_parameter) {
cargo:warning= | ^~~~~~~~~~~~~~~
```
[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5a6af707f0af
Signed-off-by: Khem Raj <raj.khem@gmail.com>
libunwind uses a C linker, so it's never even trying to link against any
C++ libraries. This removes the code which tries to drop C++ libraries,
which makes the CMake configuration simpler and allows for upgrading
GCC.
The current unwinding implementation on Haiku is messy and broken.
1. It searches weird paths for private headers, which is breaking builds
in consuming projects, such as dotnet/runtime.
2. It does not even work, due to relying on incorrect private offsets.
This commit strips all references to private headers and ports a working
signal frame implementation. It has been tested against
`tests/signal_unwind.pass.cpp` and can go pass the signal frame.
ARM64EC defines `__x86_64__`, which is sufficient to make most C/C++
code behave correctly. To preserve an external ABI compatible with
x86_64, this patch uses the x86_64 context layout and implements
`unw_getcontext` by storing the appropriate aarch64 registers according
to the mapping defined by the ARM64EC ABI.
Some code paths normalize ".." and thus don't create the directory. But some execute in a
shell thus requiring the directory to exist to be able to take the parent directory.
This patch normalizes all the `TARGET_SUBDIR` variables to avoid this issue.
The CRT __C_specific_handler function uses this for restoring registers
before calling the filter function.
This fixes the libunwind/libcxxabi forced unwind testcases on ARM and
AArch64.
This is generally very similar to the aarch64 case.
Contrary to aarch64, the public headers don't contain any definition of
a struct for interpreting this data, so we provide our own.
This is needed for forced unwind, for some testcases in
libunwind/libcxxabi.
This adds an aarch64 case for extracting the LanguageHandler and
HandlerData fields from unwind info, in UnwindCursor::getInfoFromSEH,
corresponding to the existing case for x86_64.
This uses the struct IMAGE_ARM64_RUNTIME_FUNCTION_ENTRY_XDATA; this only
became available in WinSDK 10.0.19041.0 and mingw-w64 v11.0 (or a
mingw-w64 git snapshot after April 2023).
(This is only a build-time requirement though; the format for the unwind
data has been fixed since the start of Windows 10 on ARM64, so this
doesn't impose any runtime requirement.)
Compiling with `O3`, the `early-machinelicm` pass hoisted the asm
statement to a path that has been executed unconditionally during stack
unwinding. On hardware without vector extension support, this resulted
in reading a nonexistent register.
libunwind currently supports shadow stack based on the Intel CET and
AArch64 GCS technology, but throughout related codes, the Intel-specific
keyword, "CET", is used to refer to the generic concept of control-flow
integrity/shadow stack. This patch replaces such wordings with
architecture-neutral term "shadow stack" (abbr. "shstk") to allow future
implementation to avoid using the Intel-specific "CET" term.
Similar to D90898 (Linux AArch64), D124765 (SystemZ), and D148499
(RISCV).
In this commit, I enabled two test cases, while zhuqizheng supported
with the source code development.
Co-Authored-By: zhuqizheng <zhuqizheng@loongson.cn>
Co-authored-by: zhuqizheng <zhuqizheng@loongson.cn>
When building libunwind with LTO, we found that routines, like
_Unwind_RaiseException were marked `nounwind`. This causes problems when
libunwind is then used with exception throwing code, since many of the
routines are marked `nounwind` and the compiler infers that something
like a try/catch block cannot throw resulting in a miscompile
(see #120657). Similarly, in #56825, it was pointed out that marking
_Unwind_Resume as `nounwind` causes bad exception table generation.
This patch adds the `-fexceptions` flag to the build of the C files that
define these routines, as proposed in #56825.
Fixes#56825#120657
---------
Co-authored-by: Petr Hosek <phosek@google.com>
This would previously fail the static assertions in `UnwindCursor.hpp`
due to `UnwindCursor`'s size not matching `unw_cursor_t`'s size. As is
done for MIPS N32, this just declares the appropriate size in
`__libunwind_config.h`.
* Signal frame unwinding on x86_64 from X512
* Header search for commpage_defs.h on non-standard paths
Unwind supported tests pass on Haiku x86_64
---------
Co-authored-by: Trung Nguyen <trungnt282910@gmail.com>
These two libraries don't build for `-march=armv8-a+nofp
-mabi=aapcs-soft` as a couple of uses of floating point instructions and
registers have crept in.
In libunwind, skip save/restore of FPU registers on targets without them.
In compiler-rt, fall back to the old C implementation of __arm_sc_memset when
the target doesn't have an FPU.
---------
Signed-off-by: Keith Packard <keithp@keithp.com>
Instead of building the benchmarks separately via CMake and running them
separately from the test suite, this patch merges the benchmarks into
the test suite and handles both uniformly.
As a result:
- It is now possible to run individual benchmarks like we run tests
(e.g. using libcxx-lit), which is a huge quality-of-life improvement.
- The benchmarks will be run under exactly the same configuration as
the rest of the tests, which is a nice simplification. This does
mean that one has to be careful to enable the desired optimization
flags when running benchmarks, but that is easy with e.g.
`libcxx-lit <...> --param optimization=speed`.
- Benchmarks can use the same annotations as the rest of the test
suite, such as `// UNSUPPORTED` & friends.
When running the tests via `check-cxx`, we only compile the benchmarks
because running them would be too time consuming. This introduces a bit
of complexity in the testing setup, and instead it would be better to
allow passing a --dry-run flag to GoogleBenchmark executables, which is
the topic of https://github.com/google/benchmark/issues/1827.
I am not really satisfied with the layering violation of adding the
%{benchmark_flags} substitution to cmake-bridge, however I believe
this can be improved in the future.
The runtimes used to support a build mode called the "Standalone build",
which isn't supported anymore (and hasn't been for a few years).
However, various places in the code still contained stuff whose only
purpose was to support that build mode, and some outdated documentation.
This patch cleans that up (although I probably missed some).
- Remove HandleOutOfTreeLLVM.cmake which isn't referenced anymore
- Remove the LLVM_PATH CMake variable which isn't used anymore
- Update some outdated documentation referencing standalone builds
As part of FEAT_PAuthLR, a new DWARF Frame Instruction was introduced,
`DW_CFA_AARCH64_negate_ra_state_with_pc`. This instructs Libunwind that
the PC has been used with the signing instruction. This change includes
three commits
- Libunwind support for the newly introduced DWARF Instruction
- CodeGen Support for the DWARF Instructions
- Reversing the changes made in #96377. Due to
`DW_CFA_AARCH64_negate_ra_state_with_pc`'s requirements to be placed
immediately after the signing instruction, this would mean the CFI
Instruction location was not consistent with the generated location when
not using FEAT_PAuthLR. The commit reverses the changes and makes the
location consistent across the different branch protection options.
While this does have a code size effect, this is a negligible one.
For the ABI information, see here:
853286c7ab/aadwarf64/aadwarf64.rst (id23)
While these flags semantically are relevant only for C++, we do add them
to CMAKE_REQUIRED_FLAGS if they are detected. All flags in that variable
are used both when testing compilation of C and C++ (and for detecting
libraries, which uses the C compiler driver).
Therefore, to be sure we safely can add the flags to
CMAKE_REQUIRED_FLAGS, test for the option with the C language.
This should fix compilation with GCC; newer versions of GCC do support
the -nostdlib++ option, but it's only supported by the C++ compiler
driver, not the C driver. (However, many builds of GCC also do accept
the option with the C driver, if GCC was compiled with Ada support
enabled, see [1]. That's why this issue isn't noticed in all
configurations with GCC.)
Clang does support these options in both C and C++ driver modes.
This should fix#90332.
[1]
https://github.com/llvm/llvm-project/issues/90332#issuecomment-2325099254
The personality routine `__xlcxx_personality_v0` in `libc++abi` is
hard-coded in the unwinder as the handler for EH in applications
generated by the legacy IBM C++ compiler. The symbol is resolved
dynamically using `dlopen` to avoid a hard dependency of `libunwind` on
`libc++abi` for cases such as non-C++ applications. However, `dlclose`
was incorrectly called after `dlsym` succeeded, potentially invalidating
the function pointer obtained from `dlsym` when the memory allocated for
the `dlopen` is reclaimed. This PR changes to call `dlclose` only when
`dlsym` fails.
Instead of placing artifacts for testing the runtimes at <build>/test,
place those artifacts at <build>/<project>/test. This prevents
cluttering the build directory with the runtimes' test artifacts for
everyone else.
As a drive-by, remove LIBCXX_BINARY_INCLUDE_DIR which wasn't used
anymore.
`__xlcxx_personality_v0` is the personality routine in `libc++abi` for
the EH of applications generated by the legacy IBM C++ compiler. Since
the EH info generated by the legacy compiler does not provide the
location of the personality routine, this routine is hard-coded as the
handler for legacy EH in the unwinder. The symbol is resolved
dynamically using `dlopen()` to avoid a hard dependency of `libunwind`
on `libc++abi` for cases such as non-C++ applications. The weak
declaration of `__xlcxx_personality_v0` was originally intended to
bypass `dlopen()` if the C++ application generated by the legacy
compiler is statically linked with the new LLVM C++ compiler.
Unfortunately, this causes problems with runtime linking for
Clang-compiled code using the unwinder that does not link with
`libc++abi`.
On the other hand, the C++ runtime libraries shipped for AIX are
actually stripped and statically linking is not supported. So, we can
fix the problem by removing the `__xlcxx_personality_v0` weak
declaration. Besides, `dlopen()` would work as long as the libc++abi
shared library is available.
This is a purely mechanical commit for fixing the indentation of the
runtimes' CMakeLists files after #80007. That PR didn't update the
indentation in order to make the diff easier to review and for merge
conflicts to be easier to resolve (for downstream changes).
This doesn't change any code, it only reindents it.
This patch always defines the cxx_shared, cxx_static & other top-level
targets. However, they are marked as EXCLUDE_FROM_ALL when we don't want
to build them. Simply declaring the targets should be of no harm, and it
allows other projects to mention these targets regardless of whether
they end up being built or not.
This patch basically moves the definition of e.g. cxx_shared out of the
`if (LIBCXX_ENABLE_SHARED)` and instead marks it as EXCLUDE_FROM_ALL
conditionally on whether LIBCXX_ENABLE_SHARED is passed. It then does
the same for libunwind and libc++abi targets. I purposefully avoided to
reformat the files (which now has inconsistent indentation) because I
wanted to keep the diff minimal, and I know this is an area of the code
where folks may have downstream diffs. I will re-indent the code
separately once this patch lands.
This is a reapplication of 79ee0342db, which was reverted in
a353909088 because it broke the TSAN and the Fuchsia builds.
Resolves#77654
Differential Revision: https://reviews.llvm.org/D134221
