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