9 Commits

Author SHA1 Message Date
Ryan Prichard
673484b341 [libunwind] Minor SJLJ config cleanup. NFCI.
Simplify:

    defined(__ARM_DWARF_EH__) || !defined(__arm__)

to:

    !defined(_LIBUNWIND_ARM_EHABI)

A later patch benefits from the simplicity. This change will result in
the two DWARF macros being defined when __USING_SJLJ_EXCEPTIONS__ is
defined, but:

 * That's already the case with the __APPLE__ and _WIN32 clauses.
 * That's also already the case with other architectures.
 * With __USING_SJLJ_EXCEPTIONS__, most of the unwinder is #ifdef'ed
   away.

Generally, when __USING_SJLJ_EXCEPTIONS__ is defined, most of the
libunwind code is removed by the preprocessor. e.g. None of the hpp
files are included, and almost all of the .c and .cpp files are defined
away, except in Unwind-sjlj.c. Unwind_AppleExtras.cpp is an exception
because it includes two hpp files, which it doesn't use. Remove the
unneeded includes for consistency with the general rule.

Reviewed By: steven_wu

Differential Revision: https://reviews.llvm.org/D86767
2020-09-03 15:59:45 -07:00
Louis Dionne
145acacaea [libunwind] Remove old keymgr related logic
keymgr used to be used on MacOSX <= 10.6, however we don't build libunwind
from scratch for such old systems anymore. Hence, this code isn't useful
anymore.

Differential Revision: https://reviews.llvm.org/D84677
2020-07-27 16:12:59 -04:00
Fangrui Song
f3d460ce58 [libunwind] Clean up __arm64__
`__aarch64__` is defined for the target (since the beginning of arm64 support: clang 3.5).
`__arm64__` is only defined for the Darwin OS on AArch64.

`defined(__aarch64__) || defined(__arm64__)` can be simplied as `defined(__aarch64__)`

Darwin AArch64 uses %% as the assembly separator (see AArch64MCAsmInfo.cpp).
Make the intention explicit in src/assembly.h

With this change, the libunwind code base has no reference of `__arm64__`/`__arm64`.

Reviewed By: #libunwind, ldionne, mstorsjo

Differential Revision: https://reviews.llvm.org/D77829
2020-04-09 15:46:48 -07:00
Chandler Carruth
57b08b0944 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
2019-01-19 10:56:40 +00:00
Saleem Abdulrasool
9ebbda838f SjLj: make the SjLj implementation more portable
This moves the definition of the internal helpers
`__Unwind_SjLj_GetTopOfFunctionStack` and
`__Unwind_SjLj_SetTopOfFunctionStack` into `Unwind-sjlj.c`.  These are
not extra functions specific to Apple, but rather are internal
implementation details of SjLj support in the LLVM libunwind
implementation.

This allows us to remove the internal header unwind_ext.h, as these
functions are not meant to be used as SPI either.  Because they are
static, they will be given implicit hidden visibility, but due to the
simplicity should get fully inlined into the actual use.

Use the C11 standard static TLS annotation (`_Thread_local`) if
possible, otherwise, use the Windows specific `__declspec(thread)` when
targeting Windows or the GNU `__thread` extension.  In theory, it should
be possible for this implementation to use a `pthread_setspecific` and
`pthread_getspecific` on platforms with pthreads or `SetFlsValue` and
`GetFlsValue` on Windows for non-static TLS.  However, static TLS tends
to be significantly faster, so we really should prefer that over the
dynamic TLS approach.  On Apple environments, when not building for the
loader (dyld), use the pre-allocated TLS slot in the loader rather than
the local static TLS variable.

Note that the un-threaded support of libunwind is still present as
before, however, it is unsafe to use in a threaded environment as the
cleanup stack may be mutated incorrectly due to lack of locking across
threads.  In the static TLS model, the lock is unneeded as each thread
of execution retains its own copy of the cleanup stack.

Take the opportunity to clean up the comment block, removing the iOS
specific note as the SjLj implementation can be used outside of the
context of iOS.  Convert the rest of the explanation to a doxygen style
comment block.

llvm-svn: 314632
2017-10-01 20:06:48 +00:00
Ranjeet Singh
5808011bd9 [libunwind] Clean up macro usage.
Convention in libunwind is to use !defined(FOOT) not !FOO.

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

llvm-svn: 299225
2017-03-31 15:28:06 +00:00
Ed Schouten
e2de03fd7d Fix up the places where AddressSpace.hpp is included.
The AddressSpace.hpp header declares two classes: LocalAddressSpace and
RemoteAddressSpace. These classes are only used in a very small number
of source files, but passed in as template arguments to many other
classes.

Let's go ahead and only include AddressSpace.hpp in source files where
at least one of these two classes is mentioned. This gets rid of a
cyclic header dependency that was already present, but only caused
breakage on macOS until recently.

Reported by:	Marshall Clow

llvm-svn: 297364
2017-03-09 08:04:07 +00:00
Asiri Rathnayake
6264758cc8 [libunwind] Add support for a single-threaded libunwind build
The EHABI unwinder is thread-agnostic, SJLJ unwinder and the DWARF unwinder have
a couple of pthread dependencies.

This patch makes it possible to build the whole of libunwind for a
single-threaded environment.

Reviewers: compnerd

Differential revision: https://reviews.llvm.org/D24984

llvm-svn: 282575
2016-09-28 10:57:15 +00:00
Saleem Abdulrasool
b1b1911777 unwind: move src/Unwind, include/, and test/ unwind content
This moves the majority of the unwind sources into the new project layout for
libunwind.  This was previously discussed on llvmdev at [1].  This is a
purely movement related change, with the build infrastructure currently still
residing in the libc++abi repository.

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-January/081507.html

llvm-svn: 235758
2015-04-24 19:39:17 +00:00