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

[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

show more ...

[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
anymor

[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

show more ...

[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(__aarch6

[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

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 ...

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

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

show more ...

[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

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
o

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

show more ...

[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

[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

show more ...

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].

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

show more ...