For many targets setting -fno-exceptions will prevent unwinding tables from
being generated for the test programs. As libunwind depends on the tables to
unwind the stack several tests will fail.
This change always adds -funwind-tables so that even when -fno-exceptions
is set unwind tables are generated.
fixes PR33858
Differential Revision: https://reviews.llvm.org/D37484
llvm-svn: 316657
This was missed in SVN r274744 when the WMMX part was made optional;
when made optional, some struct fields were reordered, which caused
the total struct size to grow due to padding/alignment.
llvm-svn: 316559
Most other cases that touch savedRegisters[reg] have got this check,
but these three seemed to lack it.
Differential Revision: https://reviews.llvm.org/D39206
llvm-svn: 316415
This requires _WIN32_WINNT >= 0x0600.
If someone wants to spend effort on supporting earlier versions,
one can easily add another fallback implementation based on
critical sections, or try to load SRW lock functions dynamically.
This makes sure that the FDE cache is thread safe on windows.
Differential Revision: https://reviews.llvm.org/D38704
llvm-svn: 316364
This avoids a hack for making it a no-op for windows.
Also explicitly check for _WIN32 instead of assuming it.
Differential Revision: https://reviews.llvm.org/D39156
llvm-svn: 316300
If there is no binary search table computed, the FDECount encoding is
DW_EH_PE_omit. Do not attempt to read the FDECount in such a situation
as we will read an incorrect value. binutils only writes out the
FDECount if the encoding is not DW_EH_PE_omit.
llvm-svn: 316224
libunwind is known to work on FreeBSD i386, amd64 (x86_64) and arm64.
It is the unwinder provided by the base system on all of those
architectures.
While here sort the OS list.
Differential Revision: https://reviews.llvm.org/D38900
llvm-svn: 315814
In practice, with code built with clang, there are still unresolved
issues with DW_CFA_GNU_args_size though.
Differential Revision: https://reviews.llvm.org/D38679
llvm-svn: 315498
Rather than hardcode the flag and check if the compiler supports it, use
the CMake property to get the right flag spelling for the compiler.
This makes it generally more portable.
llvm-svn: 314834
That commit incorrectly expanded the assumption that defined(__APPLE__)
implies SjLj exception handling, which only is true within ARM
code sections.
llvm-svn: 314695
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
When SJLJ exceptions are used, those functions aren't used.
This fixes build failures on ARM with SJLJ enabled (e.g. on armv7/iOS)
when built using the CMake project files.
Differential Revision: https://reviews.llvm.org/D38249
llvm-svn: 314197
This makes it match the definition used within llvm and in libgcc,
we previously got the wrong layout in 64 bit environments.
Differential Revision: https://reviews.llvm.org/D38247
llvm-svn: 314196
The changes in r297174 moved the #include of <link.h> on FreeBSD (and
probably other systems) inside of the open 'libunwind' namespace
causing various system-provided types such as pid_t to be declared in
this namespace rather than the global namespace. Fix this by moving
the relevant declarations before the 'libunwind' namespace is opened,
but still using the cleaned up declarations from r297174.
Reviewed By: ed, compnerd
Differential Revision: https://reviews.llvm.org/D38108
llvm-svn: 313920
The buildbots have shown that -Wstrict-prototypes behaves differently in GCC
and Clang so we should keep it disabled until Clang follows GCC's behaviour
llvm-svn: 312246
Clang 5 supports -Wstrict-prototypes. We should use it to catch any C
declarations that declare a non-prototype function.
rdar://33705313
Differential Revision: https://reviews.llvm.org/D36669
llvm-svn: 312240
It seems that GCC interprets `__attribute__((__aligned__))` as 8-byte
alignment on ARM, but clang does not. Explicitly specify the
double-word alignment value to ensure that the structure is properly
aligned.
llvm-svn: 311574
The C++ ABI requires that the exception object is double-word aligned.
The alignment attribute was applied to the `_Unwind_Exception` type
which is used on non-EHABI targets. On EHABI, the exception object type
is `_Unwind_Control_Block`. Apply the explicit maximal alignment on the
type to ensure that the allocation has the correct alignment.
Resolves PR33858!
llvm-svn: 311562
UnwindCursor<A, R>::getInfoFromEHABISection assumes the last
entry in the index table never corresponds to a real function.
Indeed, GNU ld always inserts an EXIDX_CANTUNWIND entry,
containing the end of the .text section. However, the EHABI specification
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038b/IHI0038B_ehabi.pdf)
does not seem to contain text that requires the presence of a sentinel entry.
In that sense the libunwind implementation isn't compliant with the specification.
This patch makes getInfoFromEHABISection examine the last entry in the index
table if upper_bound returns the end iterator.
Fixes https://bugs.llvm.org/show_bug.cgi?id=31091
Differential revision: https://reviews.llvm.org/D35265
llvm-svn: 308871
This matches the behavior of libc++abi and libc++ and ensures that
we get a working toolchain when building libunwind as part of LLVM.
Differential Revision: https://reviews.llvm.org/D34375
llvm-svn: 308380
This is going to be used by the runtime build in the multi-target
setup to allow using different install prefix for each target.
Differential Revision: https://reviews.llvm.org/D33760
llvm-svn: 307606
Mostly cargo-culted from libcxxabi, since the unwinder was forked from there in
the first place. There may still be cruft that's only applicable to libcxxabi,
but that can be addressed in-tree.
https://reviews.llvm.org/D35038
llvm-svn: 307266
It's useful to be able to disable visibility annotations entirely; for
example, if we're building libunwind static to include in another library,
and we don't want any libunwind functions getting exported out of that
library.
https://reviews.llvm.org/D34637
Patch from Thomas Anderson <thomasanderson@chromium.org>!
llvm-svn: 306442
CMake has the problem with the single dash variant because of the
space, so use the double dash with equal sign version. The compile
flag handling had a typo which caused these flag not to be properly
include. We also don't have to pass the target triple when checking
for compiler-rt since that flag is already included in compile flags
now.
Differential Revision: https://reviews.llvm.org/D32071
llvm-svn: 300419
This is a reland of commit r299796.
Turned out that we need gcc_s or compiler-rt on ARM when checking
the support for -funwind-tables which creates a dependency on
__aeabi_unwind_cpp_pr0 symbol that's provided by the compiler
runtime.
Differential Revision: https://reviews.llvm.org/D31858
llvm-svn: 300020
Since libunwind is built with -nodefaultlibs, we should be using this
option even for CMake checks to avoid any inconsistency and also to
avoid dependency on a working C++ standard library just for the setting
up the build itself. The implementation is largely similar to the one
used by libc++.
Differential Revision: https://reviews.llvm.org/D31640
llvm-svn: 299796
On certain versions of android x86, the main module `app_process` is not
built as PIE. When accessing the PT_GNU_EH_FRAME_HDR in such a
scenario, the `dlpi_addr` is 0, but the virtual address is not
relocated. Manually rebase the address to avoid an invalid memory
access.
llvm-svn: 299575
In debug mode, we have assertions that the values do not exceed the
limits of the type holding them. In order to account for the type being
derived from the AddressSpace and thus a typedef, we use
`std::numeric_limits`. Include the appropriate header.
Thanks to Marshal Clow for pointing out the missing include!
llvm-svn: 297744
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
Other source files in the source tree tend to include this header file
unconditionally. It also parses perfectly fine on ARM EHABI systems.
llvm-svn: 297175
All of the access to __exidx_*, dl_iterate_phdr(), etc. is specific to
the findUnwindSections() function. Right now all of the includes and
declarations related to them are scattered throughout the source file.
For example, for <link.h>, we have a full list of operating systems
guarding the #include, even though the code that uses dl_iterate_phdr()
miraculously doesn't use the same list.
Change the code so that findUnwindSections() is preceded by a block of
#ifdefs that share the same structure as the function itself. First
comes all of the macOS specific bits, followed by bare-metal ARM,
followed by ELF EHABI + DWARF.
This actually allows us to build a copy of libunwind without any
specific ifdefs for NetBSD, CloudABI, etc. It likely also unbreaks the
build of libunwind on FreeBSD/armv6, though I can't confirm.
Reviewed by: compnerd
Differential Revision: https://reviews.llvm.org/D30696
llvm-svn: 297174
Exception section data that we extract for DWARF gets stored as the
offset and the number of bytes. For ARM exception info, we seem to
deviate from this by storing the number of entries. Attempt to make this
more consistent.
By storing the number of bytes, we can get rid of the EHTEntry structure
declared in AddressSpace.hpp. In UnwindCursor.hpp we already have
another structure declared for the same purpose.
Reviewed by: Keith Walker
Differential Revision: https://reviews.llvm.org/D30681
llvm-svn: 297149
Peter Smith