This patch makes no assumptions on ABI past the ABI defined in
the OpenRISC 1000 spec except that the DWARF register numbers will
be 0-31 for registers r0-r31, which is true for both gcc and
clang at the moment.
llvm-svn: 246413
Use the canonical __aarch64__ predefined macro for 64-bit ARM. Apple-
specific cases are left as __arm64__. Also add an #error for unsupported
architectures to catch this sort of case in the future.
Differential Revision: http://reviews.llvm.org/D12005
llvm-svn: 244893
The register save routine in libunwind was using write-back addressing
mode to r0 for thumb, when that was not only different from the ARM
version and more importantly the register restore, but also saving the
wrong address.
Patch by Manuel Freiberger.
Fixes PR24331.
llvm-svn: 244237
To build libc++abi without libunwind, we should make sure that all
function calls to _Unwind_{Get,Set}{GR,IP}() are inlined as function
calls to _Unwind_VRS_{Get,Set}(). Otherwise, libc++abi.so will fail to
link since libgcc does not provide these symbol at all.
This commit fixes the problem by providing both the inlined version and
exported version.
llvm-svn: 243073
unw_getcontext() should return UNW_ESUCCESS on success. Therefore, the
assembly for AArch64 is incorrect because "ldr x0, #0" is a PC-relative
load instead of an immediate value load.
llvm-svn: 240648
This commit fixes the unw_step() for ARM EHABI. However, this commit
also changes the implementation details for ARM EHABI.
The first change is that the personality function should call
__gnu_unwind_frame() for default (or de facto) frame unwinding based on
the ARM-defined unwind opcode. The function __gnu_unwind_frame() will
in turn calls unw_step() which actually unwinds the frame.
The second change is that the implementation _Unwind_Backtrace() should
no longer calls unw_step() to unwind the frame; since according to ARM
EHABI, the personality function should unwind the frame for us.
Special thanks to Anton for helpful suggestion on the initial version of
this patch.
llvm-svn: 238560
Include algorithm early as otherwise you get a number of particularly unhelpful
messages about failed static assertions. This fixes compilation on Linux with
gcc.
llvm-svn: 237002
This just copies the default clang-format from the LLVM project. Many
developers use clang-format to ensure that the code is appropriately formatted,
and this commit should also test the git-svn bridge.
llvm-svn: 236767
We currently only include <link.h> on CloudABI and Linux. We can enable
it on FreeBSD as well, as it also supports the dl_iterate_phdr()
function that's provided by <link.h>.
FreeBSD, however, does not provide the ElfW() macro. Instead, the
host-specific ELF datastructures are named just Elf_XXX in addition to
the host-independent Elf32_XXX and Elf64_XXX types.
Differential Revision: http://reviews.llvm.org/D8169
Approved by: emaste
llvm-svn: 236154
This include is not currently used. It is intended for type info based
switching, which is part of the EHABI specification. However, the unwinder does
not currently support this functionality. This backwards dependency into
libc++abi is currently causing a buildbot failure, remove it until we have a
better solution.
llvm-svn: 235893
Now thta the build is split, clean up some of the warnings in the build:
cc1: warning: command line option '-nostdinc++' is valid for C++/ObjC++ but not for C
cc1: warning: command line option '-fno-rtti' is valid for C++/ObjC++ but not for C
Append the C++ specific flags specifically to the C++ sources. Avoids the
spurious warnings due to invalid flags being passed during the compilation of
C++ sources.
llvm-svn: 235797
This replicates most of the build infrastructure from libc++abi ported to
libunwind. This allows building libunwind without requiring libc++abi.
llvm-svn: 235795
These are related to libc++abi's personality routine and not core unwinding.
These have been restored in libc++abi, and are no longer needed here.
llvm-svn: 235766
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
Saleem Abdulrasool