We should not assume that the cet.h header exists just because
we're on x86 linux. Only include it if __CET__ is defined. This
makes the code more similar to what compiler-rt does in
ee423d93ea/compiler-rt/lib/builtins/assembly.h (L17)
(though that one also has a __has_include() check -- I've not found
that to be necessary).
Differential Revision: https://reviews.llvm.org/D119697
The warning was introduced with the recently merged SPARCv9
support in 2b9554b885.
The cast matches the existing surrounding cases.
Differential Revision: https://reviews.llvm.org/D119353
Add SPARC to the list of platforms for which we provide a full
unwind implementation which leads to _Unwind_Backtrace being defined within
libunwind.so.
Likewise for PPC (see D118320 for background).
Reviewed By: #libunwind, MaskRay, Arfrever
Differential Revision: https://reviews.llvm.org/D119068
Adds libunwind support for SPARCv9 (aka sparc64). This is a rebase of @kettenis' patch D32450, which I created (with his permission) because the original review has become inactive.
The changes are of a cosmetic nature to make it fit better with the new code style, and to reuse the existing SPARCv8 code, whenever possible.
Please let me know if I posted this on the wrong place. Also, the summary of the original review is reproduced below:
> This adds unwinder support for 64-bit SPARC (aka SPARCv9). The implementation was done on OpenBSD/sparc64, so it takes StackGhost into account:
>
> https://www.usenix.org/legacy/publications/library/proceedings/sec01/full_papers/frantzen/frantzen_html/index.html
>
> Since StackGhost xor's return addresses with a random cookie before storing them on the stack, the unwinder has to do some extra work to recover those. This is done by introducing a new kRegisterInCFADecrypt "location" type that is used to implement the DW_CFA_GNU_window_save opcode. That implementation is SPARC-specific, but should work for 32-bit SPARC as well. DW_CFA_GNU_window_save is only ever generated on SPARC as far as I know.
Co-authored-by: Mark Kettenis
Reviewed By: #libunwind, thesamesam, MaskRay, Arfrever
Differential Revision: https://reviews.llvm.org/D116857
Originally reported downstream in Gentoo: https://bugs.gentoo.org/832140
```
/var/tmp/portage/sys-libs/llvm-libunwind-13.0.0/work/libunwind/src/libunwind.cpp:77:3: error: #error Architecture not supported
77 | # error Architecture not supported
| ^~~~~
[...]
/var/tmp/portage/sys-libs/llvm-libunwind-13.0.0/work/libunwind/src/libunwind.cpp: In function ‘int __unw_init_local(unw_cursor_t*, unw_context_t*)’:
/var/tmp/portage/sys-libs/llvm-libunwind-13.0.0/work/libunwind/src/libunwind.cpp:80:57: error: ‘REGISTER_KIND’ was not declared in this scope
80 | new (reinterpret_cast<UnwindCursor<LocalAddressSpace, REGISTER_KIND> *>(cursor))
| ^~~~~~~~~~~~~
[...]
```
PPC is actually a supported architecture, but GCC (tested with 11.2.0)
on powerpc32 seems to only define: `__PPC__, _ARCH_PPC, __PPC,
__powerpc` and //not// `__ppc__`.
This instead uses `__powerpc__` which should be around on PPC32
and PPC64 (but we check it after PPC64, so it's fine).
Signed-off-by: Sam James <sam@gentoo.org>
Differential Revision: https://reviews.llvm.org/D118320
These two are not conceptually the same; the former is a pointer shoved
in an integer, the latter is an offset or length. On the architectures
supported by libunwind, these two have the same underlying type, namely
unsigned int on ILP32, unsigned long on LP64 and unsigned long long on
LLP64. However, on CHERI, and thus Arm's Morello, they are not the same,
as pointers are hardware capabilities that carry additional metadata
including bounds and permissions, which is preserved in uintptr_t but
not in size_t. Thus, fix all length variables to be of type size_t not
uintptr_t, as we have done downstream for a while in CHERI LLVM but did
not get round to upstreaming.
Note that dyld_unwind_sections is currently defined in Apple's headers
as genuinely using uintptr_t to represent lengths. This is a bad API and
should be fixed, which would be totally API and ABI compatible due to
size_t and uintptr_t being the same type on all supported Apple systems,
but our definition is left matching theirs until such a time as they fix
their bogus types.
This is intended to be an NFC change on all architectures supported by
LLVM upstream, only being a functional change for CHERI downstream in
CHERI LLVM.
This adds a CMake option (defaults to OFF to not be intrusive) to activate
2 new targets `install-unwind-headers` and `install-unwind-headers-stripped`.
So, for example:
cmake -S runtimes -B build -G Ninja \
-DLLVM_ENABLE_RUNTIMES='libunwind' \
-DLIBUNWIND_INSTALL_HEADERS=ON
And then, `ninja -C build install-unwind` would install headers in addition
to good ol' dylibs and archives, i.e., targets `install-unwind*` `DEPENDS`
on `install-unwind-headers*`. On the other hand,
`ninja -C build install-unwind-headers` gives you headers only.
Differential Revision: https://reviews.llvm.org/D115535
There's a lot of history behind this, so here's a summary:
1. I stopped forcing -fPIC when building the runtimes in 30f305efe2,
before the LLVM 9 release back in 2019.
2. Someone complained that libc++.a couldn't be used in shared libraries
built without -fPIC (http://llvm.org/PR43604) since the LLVM 9 release.
This had been caused by my removal of -fPIC when building libc++.a in (1).
3. I suggested two ways of fixing the issue, the first being to force
-fPIC back unconditionally (http://llvm.org/D104328), and the second
being to specify that option explicitly when building the LLVM release
(http://llvm.org/D104327). We converged on the first solution.
4. I landed D104328, which forced building the runtimes with -fPIC.
This was included in the LLVM 13.0 release.
5. People complained about that and requested that we be able to
customize this setting (basically we should have done the second
solution).
This patch makes it such that the LLVM release script will specifically
ask for building with -fPIC using CMAKE_POSITION_INDEPENDENT_CODE,
however by default the runtimes will not force that option onto users.
This patch has the unintended effect that Clang and the LLVM libraries
(not only the runtime ones like libc++) will also be built with -fPIC
in the release. It would be better if we could specify that -fPIC is to
be used only when building the runtimes, however this is left as a
future improvement. The release should probably be using a bootstrapping
build and passing those options to the stage that builds the runtimes
only, see https://reviews.llvm.org/D112748 for that change.
Differential Revision: https://reviews.llvm.org/D110261
This patch implements the following:
- Emit PACBTI-M build attributes in libunwind asm files
- Authenticate LR in DWARF32 using PACBTI
Use Armv8.1-M.Main PACBTI extension to authenticate the return address
(stored in the LR register) before moving it to the PC (IP) register.
The AUTG instruction is used with the candidate return address, the CFA,
and the authentication code that is retrieved from the saved
pseudo-register RA_AUTH_CODE.
- Authenticate LR in EHABI using PACBTI
Authenticate the contents of the LR register using Armv8.1-M.Main PACBTI
extension.
A new frame unwinding instruction is introduced (0xb4). This
instruction pops out of the stack the return address authentication
code, which is then used in conjunction with the SP and the next-to-be
instruction pointer to perform authentication.
This authentication code is popped into a new register,
UNW_ARM_PSEUDO_PAC, which is a pseudo-register.
This patch is part of a series that adds support for the PACBTI-M extension of
the Armv8.1-M architecture, as detailed here:
https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension
The PACBTI-M specification can be found in the Armv8-M Architecture Reference
Manual:
https://developer.arm.com/documentation/ddi0553/latest
The following people contributed to this patch:
- Momchil Velikov
- Victor Campos
- Ties Stuij
Reviewed By: #libunwind, danielkiss, mstorsjo
Differential Revision: https://reviews.llvm.org/D112430
When unwind step reaches the end of the stack that means the force unwind should notify the stop function.
This is not an error, it could mean just the thread is cleaned up completely.
Reviewed By: #libunwind, mstorsjo
Differential Revision: https://reviews.llvm.org/D109856
The libgcc runtime library provides __register_frame and
__deregister_frame functions, which can be used by dynamic code
generators to register an .eh_frame section, which contains one or
more Call Frame Information records, each consisting of a Common
Information Entry record followed by one or more Frame Description
Entry records. This libunwind library also provides __register_frame
and __deregister_frame functions, but they are aliases for
__unw_add_dynamic_fde and __unw_remove_dynamic_fde and thus can only
take a single FDE.
This patch adds __unw_add_dynamic_eh_frame_section and
__unw_remove_dynamic_eh_frame_section functions which explicitly use
the .eh_frame format. Clients such as the ORCv2 platform and runtime
can check for these functions and use them if unwinding is being
provided by libunwind, or fall back to __register_frame and
__deregister_frame if unwinding is provided by libgcc.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D111863
We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.
If Clang is set up to link directly against libunwind (via the
--unwindlib option, or the corresponding builtin default option),
configuring libunwind will fail while bootstrapping (before the
initial libunwind is built), because every cmake test will
fail due to -lunwind not being found, and linking the shared library
will fail similarly.
Check if --unwindlib=none is supported, and add it in that case.
Using check_c_compiler_flag on its own doesn't work, because that only
adds the tested flag to the compilation command, and if -lunwind is
missing, the linking step would still fail - instead try adding it
to CMAKE_REQUIRED_FLAGS and restore the variable if it doesn't work.
This avoids having to pass --unwindlib=none while building libunwind.
Differential Revision: https://reviews.llvm.org/D112126
Fixes D110144.
registers.getFloatRegister is not const in ARM therefor can't be called here.
Reviewed By: mstorsjo, #libunwind
Differential Revision: https://reviews.llvm.org/D110731
During a backtrace the `.cfi_undefined` for a float register causes an assert in libunwind.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D110144
Control-flow Enforcement Technology (CET), published by Intel,
introduces shadow stack feature aiming to ensure a return from
a function is directed to where the function was called.
In a CET enabled system, each function call will push return
address into normal stack and shadow stack, when the function
returns, the address stored in shadow stack will be popped and
compared with the return address, program will fail if the 2
addresses don't match.
In exception handling, the control flow may skip some stack frames
and we must adjust shadow stack to avoid violating CET restriction.
In order to achieve this, we count the number of stack frames skipped
and adjust shadow stack by this number before jumping to landing pad.
Reviewed By: hjl.tools, compnerd, MaskRay
Differential Revision: https://reviews.llvm.org/D105968
Signed-off-by: gejin <ge.jin@intel.com>
The original libunwind project defines UNW_AARCH64_* instead of UNW_ARM64_*.
Rename the enum members to match. This allows some applications with simple
`unw_init_local` usage to migrate to llvm-project libunwind.
Note: the canonical names of `UNW_ARM_D{0..31}` are now `UNW_AARCH64_V{0..31}`,
to match the original libunwind.
UNW_ARM64_* are kept for now for compatibility. Some may be unneeded and can be
cleaned up in the future.
Reviewed By: #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D107996
In some binaries, built with clang/lld, libunwind crashes
with "unsupported x86_64 register" for regNum == 16:
Differential Revision: https://reviews.llvm.org/D107919
-Wunused-but-set-variable triggers a warning even the block of code is effectively dead.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D107835
_Unwind_ForcedUnwind is not mandated by the EHABI but for compatibilty
reasons adding so the interface to higher layers would be the same.
Dropping EHABI specific _Unwind_Stop_Fn definition since it is not defined by EHABI.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D89570
Moving Itanium and ArmEHABI specific implementations to dedicated files.
This is a NFC patch.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D106461
Currently, OR1K architecture put the program counter at offset 0x128 of
the current `or1k_thread_state_t`. However, the PC is restored after
updating the thread pointer in `r3`, which causes the PC to be fetched
incorrectly.
This patch swaps the order of restoration of `r9` and `r3`, such that
the PC is restored to `r9` using the current thread state.
Patch by Oi Chee Cheung!
Reviewed By: whitequark, compnerd
Differential Revision: https://reviews.llvm.org/D107042
Building the libraries with -fPIC ensures that we can link an executable
against the static libraries with -fPIE. Furthermore, there is apparently
basically no downside to building the libraries with position independent
code, since modern toolchains are sufficiently clever.
This commit enforces that we always build the runtime libraries with -fPIC.
This is another take on D104327, which instead makes the decision of whether
to build with -fPIC or not to the build script that drives the runtimes'
build.
Fixes http://llvm.org/PR43604.
Differential Revision: https://reviews.llvm.org/D104328
This is a NFC commit to normalize how we set target properties on the
various runtime targets. A follow-up patch is going to add new properties,
and I wanted that follow-up patch to be cleaner.
This commit modifies stepWithDwarf allowing for CFI directives to
specify the value of the stack pointer.
Previously, the SP would be unconditionally set to the CFA, because it
(wrongly) stated that the CFA is the stack pointer at the call site of a
function, but that is not always true.
One situation in which that is false, is for example if you have
switched stacks. In that case if you set the CFA to the SP before
switching the stack, the CFA would be far away from where the current
call frame is located.
The CFA always points to the current call frame, and that call frame
could have a CFI directive that specifies how to restore the stack
pointer. If not, it is OK to fallback and set the SP = CFA.
This change sets SP = CFA before restoring the registers during
unwinding, allowing the stack frame to be restored with a value
different than the CFA.
Reviewed By: #libunwind, phosek
Differential Revision: https://reviews.llvm.org/D106626
"bad second level page" and "second level compressed unwind table"
can now be grepped for.
(Also remove one of the two spaces between "second" and "level"
in the second message.)
This was regressed in adf1561d6c. Since gcc does not support
`__has_feature`, this adjusts the build to use the
`__SANITIZE_ADDRESS__` macro which GCC defines to identify if ASAN is
enabled (similar to `__has_feature`). This allows building libunwind
with gcc again.
Patch by Daniel Levin!
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D104176
If you're building libunwind instrumented with ASan, `_Unwind_RaiseException`
will poison the stack and then transfer control in a manner which isn't
understood by ASan, so the stack will remain poisoned. This can cause
false positives, e.g. if you call an uninstrumented function (so it
doesn't re-poison the stack) after catching an exception. Add a call to
`__asan_handle_no_return` inside `__unw_resume` to get ASan to unpoison
the stack and avoid this.
`__unw_resume` seems like the appropriate place to make this call, since
it's used for resumption by all unwind implementations except SJLJ. SJLJ
uses `__builtin_longjmp` to handle resumption, which is already
recognized as noreturn (and therefore ASan adds the `__asan_handle_no_return`
call itself), so it doesn't need any special handling.
PR32434 is somewhat similar (in particular needing a component built
without ASan to trigger the bug), and rG781ef03e1012, the fix for that
bug, adds an interceptor for `_Unwind_RaiseException`. This interceptor
won't always be triggered though, e.g. if you statically link the
unwinder into libc++abi in a way that prevents interposing the unwinder
functions (e.g. marking the symbols as hidden, using `--exclude-libs`,
or using `-Bsymbolic`). rG53335d6d86d5 makes `__cxa_throw` call
`__asan_handle_no_return` explicitly, to similarly avoid relying on
interception.
Reviewed By: #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D103002
Summary:
This NFC patch replaces the representation of registers and the left shift operator in the PowerPC assembly code to allow it to be consumed by the GNU flavored assembler and the AIX assembler.
* Registers - change the representation of PowperPC registers from %rn, %fn, %vsn, and %vrn to the register number alone, e.g., n. The GNU flavored assembler and the AIX assembler are able to determine the register kind based on the context of the instruction in which the register is used.
* Left shift operator - use macro PPC_LEFT_SHIFT to represent the left shift operator. The left shift operator in the AIX assembly language is < instead of <<
Reviewed by: sfertile, MaskRay, compnerd
Differential Revision: https://reviews.llvm.org/D101179
These variables were introduced during early work on the runtimes build
but were obsoleted by {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_LIBRARY_DIR.
Differential Revision: https://reviews.llvm.org/D99697
immediate build failure when Cross Unwinding enabled.
Follow up patch will cleanup some Macros handling.
Differential Revision: https://reviews.llvm.org/D97762
Rename the CMake option, LIBUNWIND_HERMETIC_STATIC_LIBRARY, to
LIBUNWIND_HIDE_SYMBOLS. Rename the C macro define,
_LIBUNWIND_DISABLE_VISIBILITY_ANNOTATIONS, to _LIBUNWIND_HIDE_SYMBOLS,
because now the macro adds a .hidden directive rather than merely
suppress visibility annotations.
For ELF, when LIBUNWIND_HIDE_SYMBOLS is enabled, mark unw_getcontext as
hidden. This symbol is the only one defined using src/assembly.h's
WEAK_ALIAS macro. Other unw_* weak aliases are defined in C++ and are
already hidden.
Mach-O doesn't support weak aliases, so remove .weak_reference and
weak_import. When LIBUNWIND_HIDE_SYMBOLS is enabled, output
.private_extern for the unw_* aliases.
In assembly.h, add missing SYMBOL_NAME macro invocations, which are
used to prefix symbol names with '_' on some targets.
Fixes PR46709.
Reviewed By: #libunwind, phosek, compnerd, steven_wu
Differential Revision: https://reviews.llvm.org/D93003
This change adds support for the dwarf PC register column in arm64, allowing
CFI directives to make use of it.
As of the last revision of the DWARF for ARM 64-bit architecture[0], the pc
register has been added as a valir register, with number 32.
This allows libunwinder to restore both pc and lr, which is useful
for stack switches and signal contexts.
[0]:
f52e1ad3f8/aadwarf64/aadwarf64.rst
Reviewed By: phosek, #libunwind
Differential Revision: https://reviews.llvm.org/D96901
Null return addresses can appear at the bottom of the stack (i.e. the
frame corresponding to the entry point). Authenticating these addresses
will set the error code in the address, which will lead to a segfault
in the sigreturn trampoline detection code. Fix this problem by not
authenticating null addresses.
Differential Revision: https://reviews.llvm.org/D96560
Let's use -nostdlib++ rather than -nodefaultlibs when building libc++/libc++abi/libunwind libraries. The default is -nostdlib++ if supported by a build compiler like it is the case with clang, otherwise -nodefaultlibs is used as before.
This change is needed to avoid additional changes at the link step and not to increase the maintenance costs. If clang with -nodefaultlibs is used all the libraries which are removed but required would have to be manually added in. This set of libraries are unique and will send out.
The propose change will allow to make the link step simple for other platforms as well.
Reviewed By: #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D95875
Modify libunwind to support SjLj exception handling routines for VE.
In order to do that, we need to implement not only SjLj exception
handling routines but also a Registers_ve class. This implementation
of Registers_ve is incomplete. We will work on it later when we need
backtrace in libunwind.
Reviewed By: #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D94591
An AArch64 sigreturn trampoline frame can't currently be described
in a DWARF .eh_frame section, because the AArch64 DWARF spec currently
doesn't define a constant for the PC register. (PC and LR may need to
be restored to different values.)
Instead, use the same technique as libgcc or github.com/libunwind and
detect the sigreturn frame by looking for the sigreturn instructions:
mov x8, #0x8b
svc #0x0
If a sigreturn frame is detected, libunwind restores all the GPRs by
assuming that sp points at an rt_sigframe Linux kernel struct. This
behavior is a fallback mode that is only used if there is no ordinary
unwind info for sigreturn.
If libunwind can't find unwind info for a PC, it assumes that the PC is
readable, and would crash if it isn't. This could happen if:
- The PC points at a function compiled without unwind info, and which
is part of an execute-only mapping (e.g. using -Wl,--execute-only).
- The PC is invalid and happens to point to unreadable or unmapped
memory.
In the tests, ignore a failed dladdr call so that the tests can run on
user-mode qemu for AArch64, which uses a stack-allocated trampoline
instead of a vDSO.
Reviewed By: danielkiss, compnerd, #libunwind
Differential Revision: https://reviews.llvm.org/D90898
* Remove misnamed `PPC64_HAS_VMX` in preference of directly checking `defined(__VSX__)`.
libunwind was using "VMX" to mean "VSX". "VMX" is just another name for Altivec, while "VSX" is the vector-scalar extensions first used in POWER7. Exposing a "PPC64_HAS_VMX" define was misleading and incorrect.
* Add `defined(__ALTIVEC__)` guards around vector register operations to fix non-altivec CPUS such as the e5500.
When compiling for certain Book-E processors such as the e5500, we want to skip vector save/restore, as the Altivec registers are illegal on non-Altivec implementations.
* Add `!defined(__NO_FPRS__)` guards around traditional floating-point save/restore.
When compiling for powerpcspe, we cannot access floating point registers, as there aren't any. (The SPE on e500v2 is a 64-bit extension of the GPRs, and it doesn't have the normal floating-point registers at all.)
This fixes building for powerpcspe, although no actual handling for SPE save/restore is written yet.
Reviewed By: MaskRay, #libunwind, compnerd
Differential Revision: https://reviews.llvm.org/D91906
When building the runtimes, it's very important not to add rpaths unless
the user explicitly asks for them (the standard way being CMAKE_INSTALL_RPATH),
or to change the install name dir unless the user requests it (via
CMAKE_INSTALL_NAME_DIR).
llvm_setup_rpath() would override the install_name_dir of the runtimes
even if CMAKE_INSTALL_NAME_DIR was specified to something, which is wrong
and in fact even "dangerous" for the runtimes.
This issue was discovered when trying to build libc++ and libc++abi as
system libraries for Apple, where we set the install name dir to /usr/lib
explicitly. llvm_setup_rpath() would cause libc++ to have the wrong install
name dir, and for basically everything on the system to fail to load.
This was discovered just now because we previously used something closer
to a standalone build, where llvm_setup_rpath() wouldn't exist, and hence
not be used.
This is a revert of the following commits:
libunwind: 3a667b9bd8
libc++abi: 4877063e19
libc++: 88434fe05f
Those added llvm_setup_rpath() for consistency, so it seems reasonable
to revert.
Differential Revision: https://reviews.llvm.org/D91099
