Summary:
Fix the arm_section_length count. The meaning of the arm_section_length
field changed from num-of-elements to num-of-bytes when the
dl_unwind_find_exidx special case was removed (D30306 and D30681). The
special case was restored in D39468, but that patch didn't account for the
change in arm_section_length's meaning.

That patch worked when it was applied to the NDK's fork of libunwind,
because it never removed the special case in the first place, and the
special case is probably disabled in the Android platform's copy of
libunwind, because __ANDROID_API__ is greater than 21.

Turn the dl_unwind_find_exidx special case on unconditionally for Bionic.
Bionic's dl_unwind_find_exidx is much faster than using dl_iterate_phdr.
(e.g. Bionic stores exidx info on an internal soinfo object.)

Reviewers: thomasanderson, srhines, danalbert, ed, keith.walker.arm, mclow.lists, compnerd

Reviewed By: srhines, danalbert

Subscribers: srhines, kristof.beyls, christof, libcxx-commits

Tags: #libc

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

llvm-svn: 375275

Bug: none
Test: verify that an exception can be thrown/caught
Change-Id: I503caa5a30a5164f6021b8b5109bd647596d2d96

This fixes compilation after SVN r352966 in SEH mode.

git-svn-id: https://llvm.org/svn/llvm-project/libunwind/trunk@353010 91177308-0d34-0410-b5e6-96231b3b80d8

While Clang automatically generates the code for placement new,
g++ doesn't do that so we need to provide our own definition.

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

git-svn-id: https://llvm.org/svn/llvm-project/libunwind/trunk@352966 91177308-0d34-0410-b5e6-96231b3b80d8

This is unfinished, unused and incomplete. This could be brought back in
the future if there's a desire to build a more complete implementation,
but at the moment it's just bitrotting.

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

git-svn-id: https://llvm.org/svn/llvm-project/libunwind/trunk@352965 91177308-0d34-0410-b5e6-96231b3b80d8

When linking library dependencies, we shouldn't need to export linked
libraries to dependents. We should be explicit about this in
target_link_libraries, otherwise other targets that depend on these such
as sanitizers get repeated (and possibly even conflicting) dependencies.

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

git-svn-id: https://llvm.org/svn/llvm-project/libunwind/trunk@352688 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r352654: this broke libcxx and sanitizer bots.

git-svn-id: https://llvm.org/svn/llvm-project/libunwind/trunk@352658 91177308-0d34-0410-b5e6-96231b3b80d8

When linking library dependencies, we shouldn't need to export linked
libraries to dependents. We should be explicit about this in
target_link_libraries, otherwise other targets that depend on these such
as sanitizers get repeated (and possibly even conflicting) dependencies.

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

git-svn-id: https://llvm.org/svn/llvm-project/libunwind/trunk@352654 91177308-0d34-0410-b5e6-96231b3b80d8

This is useful when the static libunwind library is being linked into
shared libraries that may be used in with other shared libraries that
use different unwinder. We want to avoid avoid exporting libunwind
symbols in those cases. This achieved by a new CMake option which can be
enabled by libunwind vendors as needed.

The same CMake option has already been added to libc++ and libc++abi in
D55404 and D56026.

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

git-svn-id: https://llvm.org/svn/llvm-project/libunwind/trunk@352559 91177308-0d34-0410-b5e6-96231b3b80d8

We haven't eliminated C++ library dependency altogether in D57251,
UnwindCursor.hpp had an unused dependency on <algorithm> which was
pulling in other C++ headers. Removing that dependency also revealed
(correctly) that we need our own global placement new declaration. Now
libunwind should be independent of the C++ library.

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

git-svn-id: https://llvm.org/svn/llvm-project/libunwind/trunk@352553 91177308-0d34-0410-b5e6-96231b3b80d8

The existing typedef of unw_fpreg_t to uint64_t might work and be
correct for the ARM_EHABI case, but for dwarf, some cases in e.g.
DwarfInstructions.hpp convert between double and unw_fpreg_t.

When converting implicitly between double and unw_fpreg_t (uint64_t),
the values get interpreted as integers and converted to float and vice
versa, while the correct thing would be to keep the same bit pattern.

Avoid the whole issue by using the same definition of unw_fpreg_t
as all other architectures, when using dwarf unwinding on ARM.

Change assembler functions to take a void pointer instead of
unw_fpreg_t pointer, to avoid having a different mangled symbol name
depending on the actual value of this typedef.

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

git-svn-id: https://llvm.org/svn/llvm-project/libunwind/trunk@352461 91177308-0d34-0410-b5e6-96231b3b80d8