SjLj: make the SjLj implementation more portable
authorSaleem Abdulrasool <compnerd@compnerd.org>
Sun, 1 Oct 2017 20:06:48 +0000 (20:06 +0000)
committerSaleem Abdulrasool <compnerd@compnerd.org>
Sun, 1 Oct 2017 20:06:48 +0000 (20:06 +0000)
commit9ebbda838f95422b80601a164e9068fd555b2d73
treec6b0e6b13adbc4211a3ed46ed08f327a4e204b93
parentdf23a2700d3c28ddafc05bf1e069bf2c23feadb4
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
libunwind/src/CMakeLists.txt
libunwind/src/Unwind-sjlj.c
libunwind/src/Unwind_AppleExtras.cpp
libunwind/src/unwind_ext.h [deleted file]