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
While porting libunwind over to CloudABI for ARMv6, I observed that this
source file doesn't build, as it depends on dl_unwind_find_exidx(),
which CloudABI's C library was lacking. After I added that function, I
still needed to patch up libunwind to define _Unwind_Ptr.
Taking a step back, I wonder why we need to make use of this function
anyway. The unwinder already has some nice code to use dl_iterate_phdr()
to scan for a PT_GNU_EH_FRAME header. The dl_unwind_find_exidx() does
the same thing, except matching PT_ARM_EXIDX instead. We could also do
that ourselves.
This change gets rid of the dl_unwind_find_exidx() call and extends the
dl_iterate_phdr() loop. This approach has the advantage of getting rid
of some of those OS-specific #ifdefs. This now means that if an
operating system only provides dl_iterate_phdr(), it gets support for
unwinding on all architectures. There is no need to add more stuff, just
to get ARMv6 support.
This change is identical to r295944, except that it now adds the
necessary code to do bounds checking on PT_LOAD. The previous version of
this change lacked this, which didn't cause any problems on CloudABI,
but did break the Linux build bots. This is why I reverted it in
r295948.
Differential Revision: https://reviews.llvm.org/D30306
llvm-svn: 296991
When libunwind was spinned off libcxxabi, most file were copied from
libcxxabi to libunwind. However, libc++abi's toplevel LICENSE.TXT was
forgotten in the copying. It's considered a good practice to have the
license file at the root of the project, and making linunwind a separate
project was not supposed to change its licensing. Besides, several
header files refer to the LICENSE.TXT, so copy the one from libc++abi.
llvm-svn: 296358
We've been having issues with using libcxxabi and libunwind for baremetal
targets because fprintf is dependent on io functions, this patch disables calls
to fprintf when building for baremetal in release mode.
Differential Revision: https://reviews.llvm.org/D30340
llvm-svn: 296135
Even though the change works perfectly fine on CloudABI, it fails to
work on the libcxx-libcxxabi-libunwind-arm-linux-noexceptions build bot.
Looking at the code, this may be attributed to the fact that the code
doesn't take the PT_LOAD addresses into consideration.
I will rework this change to fix that and send out an updated version
for review in the nearby future.
llvm-svn: 295948
While porting libunwind over to CloudABI for ARMv6, I observed that this
source file doesn't build, as it depends on dl_unwind_find_exidx(),
which CloudABI's C library was lacking. After I added that function,
I still needed to patch up libunwind to define _Unwind_Ptr.
Taking a step back, I wonder why we need to make use of this function
anyway. The unwinder already has some nice code to use dl_iterate_phdr()
to scan for a PT_GNU_EH_FRAME header. The dl_unwind_find_exidx() does
the same thing, except matching PT_ARM_EXIDX instead. We could also do
that ourselves.
This change gets rid of the dl_unwind_find_exidx() call and extends the
dl_iterate_phdr() loop. In addition to making the code a bit shorter, it
has the advantage of getting rid of some of those OS-specific #ifdefs.
This now means that if an operating system only provides
dl_iterate_phdr(), it gets support for unwinding on all architectures.
There is no need to add more stuff, just to get ARMv6 support.
Differential Revision: https://reviews.llvm.org/D28082
llvm-svn: 295944
libunwind depends on C++ library headers. When building libunwind
as part of LLVM and libc++ is available, use its headers.
Differential Revision: https://reviews.llvm.org/D29997
llvm-svn: 295285
This causing build failure on sanitizer bots because of the unused
argument '-nostdinc++' during linking of libunwind.
This reverts commit 0e14fd1a1d37b9c6d55a2d3bc7649e5b39ce74d3.
llvm-svn: 295202
libunwind depends on C++ library headers. When building libunwind
as part of LLVM and libc++ is available, use its headers.
Differential Revision: https://reviews.llvm.org/D29800
llvm-svn: 295153
libunwind depends on C++ library headers. When building libunwind
as part of LLVM and libc++ is available, use its headers.
Differential Revision: https://reviews.llvm.org/D29573
llvm-svn: 294554
This reverts SVN r292721. Avoid the use of the GNU extension as the
preprocessor in C++11 mode requires at least one argument, and this
warning cannot be disabled, resulting in failing -Werror builds.
llvm-svn: 293257
Restore the `libunwind.h` enumeration values back to the inverted
values. This diverges from the DWARF definition of the register values.
However, this allows our header to be compatible with other unwind
implementations (e.g. HP, GNU Savannah, GCC).
The register IDs are only swapped in the header and need to be unswapped
when accessing the unwind register file. The flipped EBP and ESP only
applies on non-Apple x86 targets.
When optimizations were enabled, EBP and ESP would no longer be
equivalent. As a result, the incorrect access on Linux would manifest
as a failure to unwind the stack. We can now unwind the stack with and
without FPO on Linux x86.
Resolves PR30879!
llvm-svn: 292723
Unify the definition of `_LIBUNWIND_LOG_NON_ZERO` to make it clear what
it is defined to and make the definition unconditional. Reorder the
debug and tracing macros to be defined in the same order. NFC.
llvm-svn: 292720
This patch adjusts the out-of-tree CMake configuration so that
the stderr output is ignored when an old llvm-config is found
that doesn't support --cmakedir.
llvm-svn: 291992
Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config. Fallback to local reconstruction if llvm-config does not
support this option.
llvm-svn: 291505
These are part of the EHABI specification and are exported to be available to
users. Mark them as `_LIBUNWIND_EXPORT` like the rest of the unwind interfaces.
llvm-svn: 287283
The new LLVM runtimes directory requires the same conventions to be
followed across the runtime projects. These changes make libunwind
build under the runtimes subdirectory.
This patch contains the following changes:
* Rename LLVM_CONFIG to LLVM_CONFIG_PATH
* Check if compiler supports C++11 (required by libunwind)
Differential Revision: https://reviews.llvm.org/D26360
llvm-svn: 286308
This missing include seems to cause compilation failures on older MacOS
versions (< 10.9). This is because r270692 has introduced uint64_t into
config.h without including this header.
Patch from: Jeremy Huddleston Sequoia (jeremyhu@apple.com)
llvm-svn: 284125
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
Summary:
During building of recent compiler-rt sources on FreeBSD for arm, I
noticed that our unwind.h (which originates in libunwind) was missing
the `_US_ACTION_MASK` constant:
compiler-rt/lib/builtins/gcc_personality_v0.c:187:18: error: use of undeclared identifier '_US_ACTION_MASK'
if ((state & _US_ACTION_MASK) != _US_UNWIND_FRAME_STARTING)
^
It appears that both clang's internal unwind.h, and libgcc's unwind.h
define this constant as 3, so let's add this to libunwind's version too.
Reviewers: logan, kledzik, davide, emaste
Subscribers: joerg, davide, aemerson, emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D24222
llvm-svn: 280669
Previously most messages included a newline in the string, but a few of
them were missing. Fix these and simplify by just adding the newline in
the _LIBUNWIND_LOG macro itself.
Differential Revision: https://reviews.llvm.org/D24026
llvm-svn: 280103
For historical reasons i386 has ebp and esp swapped in the eh_frame
register numbering on at least Darwin. That is:
Darwin FreeBSD
Reg # eh_frame eh_frame DWARF
===== ======== ======== =====
4 ebp esp esp
5 esp ebp ebp
Although the UNW_X86_* constants are not intended to be coupled with
DWARF / eh_frame numbering they are currently conflated in libunwind.
Differential Revision: https://reviews.llvm.org/D22508
llvm-svn: 280099
When the unwinder is built without WMMX support, if we encounter a WMMX register
virtual operation, early rather than attempting to continue as we would not have
saved the register set anyways. This should never come down this path, but,
just in case, help it abort more explicitly.
llvm-svn: 279941
Some unwind code is purposedly old enough to work on previous architecutres
and they're guaranteed to never trigger in newer architectures, so we need
to add .arch directives to tell the compiler/assembler that it's fine and we
know what we're doing.
Fixes PR29149.
llvm-svn: 279871
When making WMMX support optional, we uncovered the switch. Add the missing
entries. Since the entry is a break leading to a dead path, it should get
optimized out yet retain the switch overage.
llvm-svn: 279180
This change allows building both shared and static version of libunwind
in a single build, sharing object files between both versions.
Differential Revision: https://reviews.llvm.org/D23233
llvm-svn: 278067
The Thumb1 version of the code for saving and restoring the unwind
context has a few bugs which prevent it from working:
* It uses the STM instruction without writeback, which is not valid for Thumb1
(It was introduced in Thumb2).
* It only saves/restores the low 8 registers, the sp and the lr, so if a
program uses r8-r12 they will not be correctly restored when throwing an
exception.
There aren't currently any Thumb1 build-bots to test this, but we have
been successfully running the libc++abi and libc++ test suites on
Cortex-M0 models, as well as some other test suites that use C++
exceptions on a downstream version of libunwind with this patch applied.
Differential Revision: https://reviews.llvm.org/D22292
llvm-svn: 276625
Summary: _Unwind_Exception is required to be double word aligned. Currently the struct is under aligned.
Reviewers: mclow.lists, compnerd, kledzik, emaste
Subscribers: emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D22543
llvm-svn: 276215
NetBSD's system unwinder is a modified version of LLVM's libunwind.
Slightly reduce diffs by updating comments to match theirs where
appropriate.
llvm-svn: 275997
These registers are only available on a limited set of ARM targets (those
based on XScale). Other targets should not have to pay the cost of these.
This patch shaves off about ~300 bytes of stack usage and ~1KB of code-size.
Differential revision: http://reviews.llvm.org/D21991
Reviewers: bcraig, compnerd
Change-Id: I2d7a1911a193bd70b123e78747e1a7d1482463c7
llvm-svn: 274744
Implement the same optimization committed under r271004 on non-EHABI,
non-SJLJ unwinder as well.
Change-Id: I7f80ed91a75d1e778b50ba87cf8fb68658a083c7
llvm-svn: 272680
The whole file is guarded with #if _LIBUNWIND_ARM_EHABI, and then in the
middle we have these two blocks, which render them pretty unused. An
artefact of a refactoring it seems.
NFC.
llvm-svn: 271737
Summary:
This patch changes the libunwind CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including config-ix.cmake.
Since these flags can affect things like check_library_exists([...]) they needed to be added before the tests are performed.
Additionally this patch adds LIBUNWIND_BUILD_32_BITS which defaults to LLVM_BUILD_32_BITS.
This patch fixes:
https://llvm.org/bugs/show_bug.cgi?id=27950https://llvm.org/bugs/show_bug.cgi?id=27959
Reviewers: jroelofs, danalbert, bcraig, rmaprath, compnerd
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20889
llvm-svn: 271458
unwind_phase1 and unwind_phase2 allocate their own copies of unw_cursor_t buffers
on the stack. This can blow-up stack usage of the unwinder depending on how these
two functions get inlined into _Unwind_RaiseException. Clang seems to inline
unwind_phase1 into _Unwind_RaiseException but not unwind_phase2, thus creating
two unw_cursor_t buffers on the stack.
One way to work-around this problem is to mark both unwind_phase1 and
unwind_phase2 as noinline. This patch takes the less compiler-dependent approach
and explicitly allocate a unw_cursor_t buffer and pass that into unwind_phase1
and unwind_phase2 functions.
A follow-up patch will replicate this behavior for the non-EHABI and non-SJLJ
implementations.
Reviewers: jroelofs, bcraig.
Differential revision: http://reviews.llvm.org/D20320
llvm-svn: 271004
Cross unwinding requires larger sizes for unw_context_t and unw_cursor_t
buffers (large enough to hold the VRS of any architecture). This is not
desirable for the most common situation where libunwind is used for native
unwinding only.
This patch makes native unwinding the default build configuration. This
will start testing the tigher (compile-time) bounds of unw_context_t
and unw_cursor_t buffers for each architecture.
Change-Id: Ic61c476a75603ca4812959c233cfe56f83dc0b00
llvm-svn: 270972
Martin Storsjo