vector is a generic C++ header, whereas __config is libc++-specific, so
we can look for it instead to guarantee we're finding a libc++
installation. This was suggested by Eric in https://reviews.llvm.org/D48694.
This is less important now that we're limiting the header search to the
specified directories (which definitely shouldn't have any other C++
library's headers anyway), but it shouldn't hurt either. There's a
chance some other library could also be providing a __config header, so
there's still a trade-off there. It would be ideal if we could check for
the presence of both __config and vector in the same directory, but
there doesn't seem to be any easy way to do that in CMake.
llvm-svn: 336034
Right now, when libc++abi is locating libc++ headers, it specifies
several search locations, but it also doesn't prevent CMake from looking
for those headers in system directories. I don't know if this was
intentional or an oversight, but it has several issues:
* We're looking specifically for the vector header, which could just as
easily be found in a libstdc++ (or other C++ library) installation.
* No system I know of places their C++ headers directly in system
include directories (they're always under a C++ subdirectory), so the
system search will never succeed.
* find_path searches system paths before the user-specified PATHS, so
if some system does happen to have C++ headers in its system include
directories, those headers will be preferred, which doesn't seem
desirable.
It makes sense to me to limit this header search to the explicitly
specified paths (using NO_DEFAULT_PATH, as is done for the other
find_path call in this file), but I'm putting it up for review in case
there's some use case I'm not thinking of.
Differential Revision: https://reviews.llvm.org/D48694
llvm-svn: 336032
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
llvm-svn: 335809
The paths output from llvm-config --cmakedir and from clang
--print-libgcc-file-name can contain backslashes, while CMake
can't handle the paths in this form.
This matches what compiler-rt already does (since SVN r203789
and r293195).
Differential Revision: https://reviews.llvm.org/D48355
llvm-svn: 335171
Patch by Ryan Prichard
If the destination type does not derive from the static type, we can skip
the search_above_dst call, but we still need to run the
!does_dst_type_point_to_our_static_type block of code. That block of code
will increment info->number_to_dst_ptr to 2, and because dest isn't derived
from static, the cast will ultimately fail.
Fixes PR33439
Reviewed as https://reviews.llvm.org/D36447
llvm-svn: 332767
This adds the test which was mistakenly not committed in r332763.
Patch by Ryan Prichard
Propagate the found_our_static_ptr and found_any_static_type flags from
__vmi_class_type_info::search_above_dst to its caller.
Fixes PR33425 and PR33487
Reviewed as https://reviews.llvm.org/D36446
llvm-svn: 332764
Patch by Ryan Prichard
Propagate the found_our_static_ptr and found_any_static_type flags from
__vmi_class_type_info::search_above_dst to its caller.
Fixes PR33425 and PR33487
Reviewed as https://reviews.llvm.org/D36446
llvm-svn: 332763
This is a follow-up change to r331150. The CL moved the macro from individual
file to build file, but the macro is missed in a test config file.
https://reviews.llvm.org/D46385
Patch from Taiju Tsuiki <tzik@chromium.org>!
llvm-svn: 331450
_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS is currently used to
bring back std::unexpected, which is removed in C++17, but still needed
for libc++abi for backward compatibility.
This macro used to define in cxa_exception.cpp only, but actually
needed for all sources that touches exceptions.
So, a build-system-level macro is better fit to define this macro.
https://reviews.llvm.org/D46056
Patch from Taiju Tsuiku <tzik@chromium.org>!
llvm-svn: 331150
This is basically part 2 of r313694.
It's a little unfortunate that I had to copy-paste atomic_support.h,
but I don't really see any alternative.
The refstring.h changes are the same as the libcxx changes in r313694.
llvm-svn: 330162
Summary:
exception_header->exceptionDestructor is a void(*)(void*) function
pointer; however, it can point to destructors like std::
exception::~exception that don't match that type signature.
Reviewers: pcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: kcc, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D45455
llvm-svn: 329629
Strictly in a conversion operator's type, a <template-param> refers to a
<template-arg> that is further ahead in the mangled name. Instead of
doing a second parse to resolve these, introduce a
ForwardTemplateReference Node and back-patch the referenced
<template-arg> when we're in the right context.
This is also a correctness fix, previously we would only do a second
parse if the <template-param> was out of bounds in the current set of
<template-args>. This lead to misdemangles (gasp!) when the conversion
operator was a member of a templated struct, for instance.
llvm-svn: 328464
Rather than eagerly propagating up parameter pack sizes in Node ctors,
find the parameter pack size during printing. This is being done to
support back-patching forward referencing <template-param>s.
llvm-svn: 328463
C++17 removes `std::unexpected_handler`, but libc++abi needs it to define
`__cxa_exception`. When building against libc++, this is easily rectified by
telling libc++ we're building the library. We already do this in the other
places where we need these symbols.
Differential Revision: https://reviews.llvm.org/D42987
llvm-svn: 324542
This commit cleans up the expression parser, using a new style:
- parse* functions now return Node pointers.
- The mangled name is now held in Db and accessed with look() and consume()
- LLVM coding style
This style is meant to avoid the 2 most common types of bugs in the
old demanger, namely misusing the Names stack (ie, calling back() on
empty) and going out of bounds on the mangled name. I also think it
makes the demangler a lot cleaner.
Differential revision: https://reviews.llvm.org/D41887
llvm-svn: 324111
This commit changes how variadic templates are represented in the
demangler, in order to fix some longstanding bugs. Now instead of
expanding variadic templates during parsing, the expansion is done
during printing by reusing the unexpanded AST. This allows the
demangler to handle cases where multiple packs contribute to a single
production, and correctly handle "Dp" and "sp" productions, which
corrispond to pack expansions in type and expression contexts.
Differential revision: https://reviews.llvm.org/D41885
llvm-svn: 323906
[cmake] [libcxxabi] Call llvm_setup_rpath() when adding shared libraries.
Clang and llvm already use llvm_setup_rpath(), so this change will
help standarize rpath usage across all projects.
Differential Revision: https://reviews.llvm.org/D42460
llvm-svn: 323495
Shoaib Meenai pointed out this will break standalone builds can be built without llvm.
Differential Revision: https://reviews.llvm.org/D42460
llvm-svn: 323458
Clang and llvm already use llvm_setup_rpath(), so this change will
help standarize rpath usage across all projects.
Differential Revision: https://reviews.llvm.org/D42460
llvm-svn: 323455
This fixes:
src/cxa_default_handlers.cpp:25:13: error: unused function 'demangling_terminate_handler' [-Werror,-Wunused-function]
Patch by Thomas Anderson!
Differential Revision: https://reviews.llvm.org/D42399
llvm-svn: 323397
When CMAKE_SYSROOT or CMAKE_FIND_ROOT_PATH is set, cmake
recommends setting CMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY
globally which means find_path() always prepends CMAKE_SYSROOT or
CMAKE_FIND_ROOT_PATH to all paths used in the search.
However, these find_path() invocations are looking for paths in
the libcxx and libunwind projects on the host system, not the
target system, which can be done by passing
NO_CMAKE_FIND_ROOT_PATH.
Differential Revision: https://reviews.llvm.org/D41623
llvm-svn: 323145
Summary:
Don't print, possibly erroneous, warning if
LIBCXXABI_INCLUDE_TESTS is false.
This patch fixes a problem introduced in r291367.
Differential Revision: https://reviews.llvm.org/D42229
llvm-svn: 322870
This patch updates libc++abi's HandleOutOfTreeLLVM.cmake to match
libc++'s -- and more importantly, to fix a bug where llvm-lit wasn't
found/created when libc++abi was built out-of-tree. This prevented
the test suite from running.
llvm-svn: 322768
Summary:
We want to automatically copy the appropriate mailing list
for review requests to the libc++abi repository.
For context, see the proposal and discussion here:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/056032.html
Similar to D40500, I set up a new Diffusion repository with callsign
"CXXA" for libc++abi:
https://reviews.llvm.org/source/libcxxabi/
This explicitly updates libcxxabi's .arcconfig to point to the new
CXX repository in Diffusion, which will let us use Herald rule H268.
Reviewers: phosek, beanz, EricWF, compnerd
Reviewed By: phosek
Subscribers: cfe-commits, klimek, sammccall, dlj, bkramer
Differential Revision: https://reviews.llvm.org/D40501
llvm-svn: 319713
LLVM is gaining install-*-stripped targets to perform stripped installs,
and in order for this to be useful for install-distribution, all
potential distribution components should have stripped installation
targets. LLVM has a function to create these install targets, but since
we can't use LLVM CMake functions in libc++abi, let's do it manually.
Differential Revision: https://reviews.llvm.org/D40681
llvm-svn: 319499
object is sufficiently aligned.
r303175 annotated field unwindHeader of __cxa_exception with attribute
'aligned' to ensure the thrown object following the __cxa_exception
header was sufficiently aligned. This caused changes in the field
offsets of __cxa_exception relative to the start of the thrown object,
which was an ABI breaking change for some clients.
Instead of annotating field unwindHeader, this commit inserts extra
space before the header. This ensures the thrown object following the
header is sufficiently aligned without changing the field offsets, thus
avoiding any ABI breakages.
rdar://problem/25364625
rdar://problem/35556163
llvm-svn: 319123
This is useful in cases where we only build static library and
libc++abi.a is combined with libc++.a into a single archive in which
case we don't want to have libc++abi.a installed separately. The same
option is already provided by libcxx CMake build.
Differential Revision: https://reviews.llvm.org/D40194
llvm-svn: 318568
When using LLVM unwinder and static unwinder option is set, merge
libunwind and libc++abi objects into a single archive. libc++ already
supports merging libc++abi.a and libc++.a into a single archive; with
this change, it is possible to also include libunwind.a in the same
archive which is useful when doing static link and using libc++ as
a default C++ library and compiler-rt as a default runtime library.
Differential Revision: https://reviews.llvm.org/D39949
llvm-svn: 318563
compiler-rt recently added the __asan_handle_no_return() function that libc++abi
needs to use, however older versions of compiler-rt don't declare this interface
publicly and that breaks the libc++abi build.
This patch attempts to fix the issues by declaring the asan function explicitly,
so we don't depend on compiler-rt to provide the declaration.
llvm-svn: 313308
Summary:
compiler-rt recently added the `__asan_handle_no_return()` function that libc++abi needs to use, however older versions of compiler-rt don't provide this interface and that breaks the libc++abi build.
This patch attempts to fix the issues by using a macro to detect if `asan_interface.h` is new enough to provide the function.
See D37871
Reviewers: phosek, vitalybuka
Reviewed By: phosek, vitalybuka
Subscribers: dberris, cfe-commits
Differential Revision: https://reviews.llvm.org/D37872
llvm-svn: 313304
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/D37229
llvm-svn: 313215
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.
This is a re-land of r311045, which has become safe after r311869
changed compiler-rt to declare __asan_handle_no_return.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D37229
llvm-svn: 312606
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
Erik Pilkington