No intended behavior change on Linux and Mac OS X. On Windows, having libcxxabi
in one's checkout should now no longer break running cmake. (cl.exe supports
c++11, but doesn't understand a -std= flag.)
llvm-svn: 213214
The cmake files for libc++abi and the unwinder weren't linking against
libpthread or an unwind library. If the tests were linked with
-Wl,--as-needed, these libraries wouldn't be linked, causing them to
fail.
Patch contributed by İsmail Dönmez.
llvm-svn: 212958
Note: The unwinder currently only works on Darwin and on ARM Linux.
Non-ARM Linux support is not yet implemented, and will fail to build.
llvm-svn: 212824
This makes running libcxxabi tests on Linux _much_ easier.
Adds a check-libcxxabi target to cmake.
Also defaults to building a dynamic libc++abi. This is so that the
default options still test the libc++abi that is being built. There are
two problems with testing a static libc++abi. In the case of a
standalone build, the tests will link the system's libc++, which might
not have been built against our libc++abi. In the case of an in tree
build, libc++ will prefer a dynamic libc++abi from the system over a
static libc++abi from the output directory.
llvm-svn: 212672
This commit reverts the LSDA-related change in r211745.
The r211745 adds a new argument to scan_eh_tab(), i.e. lsda.
However, IMO, calling _Unwind_GetLanguageSpecificData() directly in
scan_eh_tab() was more intuitive and reduces several function call
to _Unwind_GetLanguageSpecificData() in __cxx_personality_v0().
llvm-svn: 212037
This was written by:
Albert Wong <ajwong@chromium.org>
Antoine Labour <piman@chromium.org>
Dana Jansen <danakj@chromium.org
Jonathan Roelofs <jonathan@codesourcery.com>
Nico Weber <thakis@chromium.org>
llvm-svn: 211743
The new code will be behind a LIBCXXABI_ARM_EHABI define (so that platforms
that don't want it can continue using e.g. SJLJ). This commit mostly just
adds the LIBCXXABI_ARM_EHABI define.
llvm-svn: 211739
There was a single problem in cxa_demangle.cpp, where gcc would complain
`error: changes meaning of 'String'` about the line `typedef String String;`.
According to 3.3.7p2, this diagnostic is allowed (but not required, so clang
does not have to report this).
As a fix, make string_pair a template and pass String as template parameter.
This fixes the error with gcc and also removes some repetition from the code.
No behavior change.
llvm-svn: 209909
determine whether we get a mangling for a return type, rather than trying to
figure it out based on whether the mangled name ended with a '>'.
llvm-svn: 208611
To allow the compilation with gcc, we can't use the
__has_feature(cxx_noexcept) to detect the default destructor
exception specification, which is noexcept(true) by default
in C++11. We should use __cplusplus >= 201103L instead.
llvm-svn: 208465
The was working because, given __APPLE__, _LIBUNWIND_BUILD_SJLJ_APIS was set to
__arm__, but other ARM targets not using SJ/LJ will fail to compile.
llvm-svn: 206941
opcode is VAX. A function call pushes the number of arguments given onto
the stack and "ret" will pop it automatically. The FDE of the caller
contains the amount of stack space used for arguments (and possibly
extra padding), so unwinding has to compensate for this when "returning"
from a function. This is exactly the case when step() is done. The
existing handling in unw_set_reg no longer makes sense.
llvm-svn: 204290
This is in preparation for landing an implementation of unw_getcontext
on a system where it's mangled 'unw_getcontext', not '_unw_getcontext'.
llvm-svn: 197523
type_info* will work for typeids from the same compiled file but fail
for typeids from a DLL and an executable. Among other things, exceptions
are not caught by handlers since can_catch() returns false.
Defining _LIBCXX_DYNAMIC_FALLBACK does not help since can_catch() calls
is_equal() with use_strcmp=false so the string names are not compared.
This patch compares typeids first (cheap) and only they are different
calls strcmp.
llvm-svn: 195502
__attribute__ (( unavailable )) is for Apple specific builds. Create a macro
to conditionalise the usage of the macro. This is to aid in porting the
unwinder to other platforms.
llvm-svn: 192868
realized, it is not complete. It relies on some _Unwind_* functions to be
supplied by the OS. That means it cannot be ported to platforms that don’t
already have an unwinder.
Years ago Apple wrote its own unwinder for MacOSX and iOS. To make libcxxabi
complete, Apple has decided the source code for its unwinder can be contributed
to the open source LLVM libcxxabi project, with a dual licensed under LLVM
and MIT license.
So, I’ve spent some time cleaning up the sources to make them conform with
LLVM style and to conditionalize the sources in a way that should make it
easier to port to other platforms. The sources are in a separate "Unwind"
directory under "src" in libcxxabi.
Background:
Most architectures now use "zero cost" exceptions for C++. The zero cost means
there are no extra instructions executed if no exceptions are thrown. But if
an exception is thrown, the runtime must consult side tables and figure out how
to restore registers and "unwind" from the current stack frame to the catch
clause. That ability to modify the stack frames and cause the thread to resume
in a catch clause with all registers restored properly is the main purpose
of the unwinder.
This unwinder has two levels of API. The high level APIs are the _Unwind_*
functions which the cxa_* exception functions in libcxxabi require. The low
level APIs are the unw_* functions which are an interface defined by the the
old HP libunwind project (which shares no code with this unwinder).
llvm-svn: 192136
Nico Weber