[libunwind] Add SystemZ support

Add support for the SystemZ (s390x) architecture to libunwind.

Support should be feature-complete with the exception of
unwinding from signal handlers (to be added l

[libunwind] Add SystemZ support

Add support for the SystemZ (s390x) architecture to libunwind.

Support should be feature-complete with the exception of
unwinding from signal handlers (to be added later).

Reviewed by: MaskRay

Differential Revision: https://reviews.llvm.org/D124248

show more ...

[libunwind][AIX] implementation of the unwinder for AIX

Summary:
This patch contains the implementation of the unwinder for IBM AIX.

AIX does not support the eh_frame section. Instead, the tracebac

[libunwind][AIX] implementation of the unwinder for AIX

Summary:
This patch contains the implementation of the unwinder for IBM AIX.

AIX does not support the eh_frame section. Instead, the traceback table located at the end of each function provides the information for stack unwinding and EH. In this patch macro _LIBUNWIND_SUPPORT_TBTAB_UNWIND is used to guard code for AIX traceback table based unwinding. Function getInfoFromTBTable() and stepWithTBTable() are added to get the EH information from the traceback table and to step up the stack respectively.

There are two kinds of LSDA information for EH on AIX, the state table and the range table. The state table is used by the previous version of the IBM XL compiler, i.e., xlC and xlclang++. The DWARF based range table is used by AIX clang++. The traceback table has flags to differentiate these cases. For the range table, relative addresses are calculated using a base of DW_EH_PE_datarel, which is the TOC base of the module where the function of the current frame belongs.

Two personality routines are employed to handle these two different LSDAs, __xlcxx_personality_v0() for the state table and __xlcxx_personality_v1() for the range table. Since the traceback table does not have the information of the personality for the state table approach, its personality __xlcxx_personality_v0() is dynamically resolved as the handler for the state table. For the range table, the locations of the LSDA and its associated personality routine are found in the traceback table.

Assembly code for 32- and 64-bit PowerPC in UnwindRegistersRestore.S and UnwindRegistersSave.S are modified so that it can be consumed by the GNU flavor assembler and the AIX assembler. The restoration of vector registers does not check VRSAVE on AIX because VRSAVE is not used in the AIX ABI.

Reviewed by: MaskRay, compnerd, cebowleratibm, sfertile, libunwind

Differential Revision: https://reviews.llvm.org/D100132

show more ...

[libunwind] [sparc] Add SPARCv9 support

Adds libunwind support for SPARCv9 (aka sparc64). This is a rebase of @kettenis' patch D32450, which I created (with his permission) because the original revi

[libunwind] [sparc] Add SPARCv9 support

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

show more ...

[unwind] fix build with GCC on PPC32

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

[unwind] fix build with GCC on PPC32

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 <[email protected]>
Differential Revision: https://reviews.llvm.org/D118320

show more ...

[libunwind] Add an interface for dynamic .eh_frame registration

The libgcc runtime library provides __register_frame and
__deregister_frame functions, which can be used by dynamic code
generators to

[libunwind] Add an interface for dynamic .eh_frame registration

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

show more ...

[runtimes][NFC] Remove filenames at the top of the license notice

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 st

[runtimes][NFC] Remove filenames at the top of the license notice

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.

show more ...

[libunwind] Support stack unwind in CET environment

Control-flow Enforcement Technology (CET), published by Intel,
introduces shadow stack feature aiming to ensure a return from
a function is direct

[libunwind] Support stack unwind in CET environment

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 <[email protected]>

show more ...

unwind: allow building with GCC

This was regressed in adf1561d6ce8. Since gcc does not support
`__has_feature`, this adjusts the build to use the
`__SANITIZE_ADDRESS__` macro which GCC defines to i

unwind: allow building with GCC

This was regressed in adf1561d6ce8. 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

show more ...

[libunwind] Inform ASan that resumption is noreturn

If you're building libunwind instrumented with ASan, `_Unwind_RaiseException`
will poison the stack and then transfer control in a manner which is

[libunwind] Inform ASan that resumption is noreturn

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

show more ...

[libunwind] This adds support in libunwind for rv32 hard float
and soft-float for both rv32 and rv64.

Differential Revision: https://reviews.llvm.org/D80690

[VE] Support VE in libunwind

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 Regis

[VE] Support VE in libunwind

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

show more ...

[libunwind] add hexagon support

[libunwind][RISCV] Add 64-bit RISC-V support

Summary:
Add unwinding support for 64-bit RISC-V.

This is from the FreeBSD implementation with the following minor
changes:

- Renamed and renumbered DW

[libunwind][RISCV] Add 64-bit RISC-V support

Summary:
Add unwinding support for 64-bit RISC-V.

This is from the FreeBSD implementation with the following minor
changes:

- Renamed and renumbered DWARF registers to match the RISC-V ABI [1]
- Use the ABI mneumonics in getRegisterName() instead of the exact
register names
- Include checks for __riscv_xlen == 64 to facilitate adding the 32-bit
ABI in the future.

[1] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md

Patch by Mitchell Horne (mhorne)

Reviewers: lenary, luismarques, compnerd, phosek

Reviewed By: lenary, luismarques

Subscribers: arichardson, sameer.abuasal, abidh, asb, aprantl, krytarowski, simoncook, kito-cheng, christof, shiva0217, rogfer01, rkruppe, PkmX, psnobl, benna, lenary, s.egerton, luismarques, emaste, cfe-commits

Differential Revision: https://reviews.llvm.org/D68362

show more ...

unwind: remove a could of extraneous `else` (NFC)

Simplify `if return else return` by removing the unnecessary `else`.

llvm-svn: 372233

[libunwind] Fix the typo in unw_save_vfp_as_X alias

This was accidentaly introduced in r357640.

llvm-svn: 358164

[libunwind] Export the unw_* symbols as weak symbols

libunwind defines the _Unwind_* ABI used by libc++abi. This ABI is a
stable quasi-standard common between multiple implementations such as
LLVM a

[libunwind] Export the unw_* symbols as weak symbols

libunwind defines the _Unwind_* ABI used by libc++abi. This ABI is a
stable quasi-standard common between multiple implementations such as
LLVM and GNU. The _U* symbol name space is also safely within the symbol
name space that standard C & C++ reserve for the implementation.

Futhermore, libunwind also defines several unw_* symbols, and references
these from the _Unwind_* entry points so the standard/reserved part of
the ABI is dependent on the unw_* part of the ABI. This is not OK for a
C or C++ implementation. The unw_* symbols are reserved for C and extern
"C" used by application code.

This change renames each unw_* function to __unw* and adds a weak alias
unw_* to keep the public <libunwind.h> ABI unchanged for backwards
compatibility. Every reference to unw_* in the implementation has been
changed to use __unw* so that if other unw_* definitions are in force
because nothing uses <libunwind.h> in a particular program, no _Unwind*
code path depends on any unw_* symbol. Furthemore, __unw_* symbols are
hidden, which saves PLT overhead in the shared library case.

In the future, we should cconsider untangling the unw_* API/ABI from the
_Unwind_* API/ABI. The internal API backing the _Unwind_* ABI
implementation should not rely on any nonstandard symbols not in the
implementation-reserved name space. This would then allow separating the
_Unwind_* API/ABI from unw_* entirely, but that's a more substantial
change that's going to require more significant refactoring.

Differential Revision: https://reviews.llvm.org/D59921

llvm-svn: 357640

show more ...

[libunwind] Provide placement new definition

While Clang automatically generates the code for placement new,
g++ doesn't do that so we need to provide our own definition.

Differential Revision: htt

[libunwind] Provide placement new definition

While Clang automatically generates the code for placement new,
g++ doesn't do that so we need to provide our own definition.

Differential Revision: https://reviews.llvm.org/D57455

llvm-svn: 352966

show more ...

[libunwind] Remove the remote unwinding support

This is unfinished, unused and incomplete. This could be brought back in
the future if there's a desire to build a more complete implementation,
but a

[libunwind] Remove the remote unwinding support

This is unfinished, unused and incomplete. This could be brought back in
the future if there's a desire to build a more complete implementation,
but at the moment it's just bitrotting.

Differential Revision: https://reviews.llvm.org/D57252

llvm-svn: 352965

show more ...

Drop the dependency on <algorithm>, add placement new inline

We haven't eliminated C++ library dependency altogether in D57251,
UnwindCursor.hpp had an unused dependency on <algorithm> which was
pul

Drop the dependency on <algorithm>, add placement new inline

We haven't eliminated C++ library dependency altogether in D57251,
UnwindCursor.hpp had an unused dependency on <algorithm> which was
pulling in other C++ headers. Removing that dependency also revealed
(correctly) that we need our own global placement new declaration. Now
libunwind should be independent of the C++ library.

Differential Revision: https://reviews.llvm.org/D57262

llvm-svn: 352553

show more ...

Revert "[libunwind] Drop the dependency on <algorithm>, add placement new inline"

This reverts commit r352384: this broke on ARM as UnwindCursor.hpp
still has some C++ library dependencies.

llvm-sv

Revert "[libunwind] Drop the dependency on <algorithm>, add placement new inline"

This reverts commit r352384: this broke on ARM as UnwindCursor.hpp
still has some C++ library dependencies.

llvm-svn: 352427

show more ...

[libunwind] Drop the dependency on <algorithm>, add placement new inline

We haven't eliminated C++ library dependency altogether in D57251,
UnwindCursor.hpp had an unused dependency on <algorithm> w

[libunwind] Drop the dependency on <algorithm>, add placement new inline

We haven't eliminated C++ library dependency altogether in D57251,
UnwindCursor.hpp had an unused dependency on <algorithm> which was
pulling in other C++ headers. Removing that dependency also revealed
(correctly) that we need our own global placement new declaration. Now
libunwind should be independent of the C++ library.

Differential Revision: https://reviews.llvm.org/D57262

llvm-svn: 352384

show more ...

[libunwind] Use placement new to avoid dependency C++ library

The rest of libunwind already uses placement new, these are the only
places where non-placement new is being used introducing undesirabl

[libunwind] Use placement new to avoid dependency C++ library

The rest of libunwind already uses placement new, these are the only
places where non-placement new is being used introducing undesirable
C++ library dependency.

Differential Revision: https://reviews.llvm.org/D57251

llvm-svn: 352245

show more ...

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351648

show more ...

[Sparc] Add Sparc V8 support

Summary:
Adds the register class implementation for Sparc.
Adds support for DW_CFA_GNU_window_save.
Adds save and restore context functionality.

Adds getArch() function

[Sparc] Add Sparc V8 support

Summary:
Adds the register class implementation for Sparc.
Adds support for DW_CFA_GNU_window_save.
Adds save and restore context functionality.

Adds getArch() function to each Registers_ class to be able to separate
between DW_CFA_AARCH64_negate_ra_state and DW_CFA_GNU_window_save which
are both represented by the same constant.

On Sparc the return address is the address of the call instruction, so
an offset needs to be added when returning to skip the call instruction
and its delay slot. If the function returns a struct it is also necessary
to skip one extra instruction on Sparc V8.

Reviewers: jyknight, mclow.lists, mstorsjo, compnerd

Reviewed By: jyknight, compnerd

Subscribers: jgorbe, mgorny, christof, llvm-commits, fedor.sergeev, JDevlieghere, ldionne, libcxx-commits

Differential Revision: https://reviews.llvm.org/D55763

llvm-svn: 351044

show more ...

Revert "[Sparc] Add Sparc V8 support"

This reverts commit r350705.

llvm-svn: 350787