The ASan runtime on many systems intercepts cxa_throw just so it
can call asan_handle_no_return first. Some newer systems such as
Fuchsia don't use interceptors on standard library functions at all,
but instead use sanitizer-instrumented versions of the standard
libraries. When libc++abi is built with ASan, cxa_throw can just
call asan_handle_no_return itself so no interceptor is required.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D36599
llvm-svn: 311045
The demangler now demangles by producing an AST, then traverses that
AST to produce a demangled name. This is done for performance reasons,
now the demangler doesn't manuiplate std::strings, which hurt
performance and caused string operations to be inlined into the
parser, leading to large code size and stack usage.
Differential revision: https://reviews.llvm.org/D35159
llvm-svn: 309340
This patch removes the dependancy on libc++'s __refstring header,
which was only a header in the first place so that libc++abi could
build library code using it, and not because libc++ needed it in
the headers.
This patch allows libc++ to stop shipping <__refstring> publicaly
at the cost of duplicating it across projects. Ideally libc++abi
would always require the libc++ sources when building, but that's
a separate discussion I plan to start on the mailing lists shortly.
llvm-svn: 307748
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/D33761
llvm-svn: 307611
Rather than manually checking for support for the spelling of the C++
standard, indicate to CMake that we require that the compiler support
C++11 and that we compile without the GNU extensions. This simplifies
the flags handling in libc++abi itself by relying on CMake to translate
the flag and add it as appropriate.
llvm-svn: 305175
Use the POSITION_INDEPENDENT_CODE target property to indicate that we
should be building with -fPIC or the equivalent flag based on the
toolchain that we are using. This makes the check more portable and
simplifies the flags management. Because we don't want this setting to
propagate in the case of an in-tree build, set the property on the
targets we construct explicitly rather than setting
CMAKE_POSITION_INDEPENDENT_CODE to ON globally.
llvm-svn: 305174
Use the C++11 (formalised in C++17) tag to indicate a fallthrough in the
switch case. Silences a -Wimplicit-fallthrough warning with gcc:7
llvm-svn: 305173
Refactor cmake to remove dependence on LLVM's cmake modules.
This improves handling of cmake checks when cross compiling and brings
libcxxabi in line with libcxx and other project modules.
Differential revision: https://reviews.llvm.org/D33635
llvm-svn: 304374
As per r241993, libunwind_ext.h is not used anymore, and thus only the public libunwind includes are needed.
This eases distro packaging efforts and removes an unneeded requirement for out-of-tree building.
Reviewed as D33178
llvm-svn: 304359
The problem was that if base_name() was called from a context without
an actual base name, it could gulp up the entire string, which can
result in recursive duplications. The fix is to be more strict as to
what qualifies as a base name.
Differential revision: https://reviews.llvm.org/D33637
llvm-svn: 304113
Summary:
Previously if we parsed a constructor then we set parsed_ctor_dtor_cv
to true and never reseted it. This causes issue when a template argument
references a constructor (e.g. type of lambda defined inside a
constructor) as we will have the parsed_ctor_dtor_cv flag set what will
cause issues when parsing later arguments.
Reviewers: EricWF, compnerd
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33385
llvm-svn: 303737
The problem is that multiple types could have been parsed from parse_type(),
which the lamdba parameter parsing didn't handle.
Differential revision: https://reviews.llvm.org/D33368
llvm-svn: 303718
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
This recommits r302978 and r302981, which were reverted in r303016
because a libcxx test was failing on an AArch64 bot. I also modified the
libcxxabi test case to check the alignment of the pointer returned by
__cxa_allocate_exception rather than compiling the test with -O1 and
checking whether it segfaults.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 303175
For ARM EHABI, _Unwind_Exception is an alias of _Unwind_Control_Block,
which is not aligned, so we shouldn't align unwindHeader either.
rdar://problem/25364625
llvm-svn: 302981
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
This recommits r302763 with fixes to RUN lines in the test case.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 302978
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 302763