This change is similar to r356150, with the same motivation. The
only difference is that the method used to merge libunwind.a and
libc++abi.a had to be changed to use the same approach as libc++
since we no longer produce object libraries that could be linked
together as we did before. We reuse the libc++ script for merging
archives to avoid duplication between the two projects.
Differential Revision: https://reviews.llvm.org/D60173
llvm-svn: 357635
This is on by default, since on many platforms and configurations
libc++abi.a gets statically linked into shared libraries and/or
PIE executables.
This change is a followup to https://reviews.llvm.org/D60005 which
allows us to default to PIC code, but disable this if needed (for
example on WebAssembly where PIC code its currently compatible with
static linking).
Differential Revision: https://reviews.llvm.org/D60049
llvm-svn: 357551
With the current WebAssembly backend, objects built with -fPIC are not
compatible with static linking. libc++abi was (mistakenly?) adding
-fPIC to the objects it was including in a static library.
IIUC this change should also mean the static build can be more efficient
on all platforms.
Differential Revision: https://reviews.llvm.org/D60005
llvm-svn: 357322
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/<target> and include/ directories, leaving resource directory only
for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59013
llvm-svn: 355665
This matters on OSX because static linking orders is also the order dyld
uses to search for libs (the default - Two-level namespace). If system
libs (including unwind lib) are specified before local unwind lib, local
unwind lib would never be picked up by dyld.
Before:
$ otool -L lib/libc++abi.dylib
@rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
@rpath/libunwind.1.dylib (compatibility version 1.0.0, current version 1.0.0)
After:
$ otool -L lib/libc++abi.dylib
@rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)
@rpath/libunwind.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
Thanks to Yuanfang Chen for the patch.
Differential Revision: https://reviews.llvm.org/D57496
llvm-svn: 355241
This include doesn't seem to be needed for the standalone build (it's
not being used by libc++ build either), but introduces unnecessary
dependency because HandleOutOfTreeLLVM performs checks that require
a working C++ library. We shouldn't require a working C++ library to
build libc++abi or libc++ (it's what we're building after all).
Differential Revision: https://reviews.llvm.org/D58333
llvm-svn: 354284
This changes add_custom_libcxx to also build libcxxabi and merges
the two into a static and hermetic library.
There are multiple advantages:
1) The resulting libFuzzer doesn't expose C++ internals and looks
like a plain C library.
2) We don't have to manually link in libstdc++ to provide cxxabi.
3) The sanitizer tests cannot interfere with an installed version
of libc++.so in LD_LIBRARY_PATH.
Differential Revision: https://reviews.llvm.org/D58013
llvm-svn: 354212
We build libc++ and libc++abi with -nodefaultlibs, so -rtlib=compiler-rt
has no effect and results in an 'argument unused during compilation'
warning which breaks the build when using -Werror. We can therefore drop
-rtlib=compiler-rt without any functional change; note that the actual
compiler-rt linking is handled by HandleCompilerRT.
Differential Revision: https://reviews.llvm.org/D58084
llvm-svn: 353786
We're building tests with -nostdlib which means that we need to
explicitly include the builtins library. When using libgcc (default)
we can simply include -lgcc_s on the link line, but when using
compiler-rt builtins we need a complete path to the builtins library.
This path is already available in CMake as <PROJECT>_BUILTINS_LIBRARY,
so we just need to pass that path to lit and if config.compiler_rt is
true, link it to the test.
Prior to this patch, running tests when compiler-rt is being used as
the builtins library was broken as all tests would fail to link, but
with this change running tests when compiler-rt bultins library is
being used should be supported.
Differential Revision: https://reviews.llvm.org/D56701
llvm-svn: 353208
There are several changes:
- Don't stringify Pythonized bools (that's why we're Pythonizing them)
- Support specifying target and sysroot via CMake variables
- Use consistent spelling for --target, --sysroot, --gcc-toolchain
llvm-svn: 353137
CMake has a standard way of setting target triple, sysroot and external
toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and
CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into
corresponding --target=, --sysroot= and --gcc-toolchain= variables add
included appended to CMAKE_<LANG>_FLAGS.
libunwind, libc++abi, libc++ provides their own mechanism through
<PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN
variables. These are also passed to lit via lit.site.cfg, and lit config
uses these to set the corresponding compiler flags when building tessts.
This means that there are two different ways of setting target, sysroot
and toolchain, but only one is properly supported in lit. This change
extends CMake build for libunwind, libc++abi and libc++ to also support
the CMake variables in addition to project specific ones in lit.
Differential Revision: https://reviews.llvm.org/D57670
llvm-svn: 353084
When linking library dependencies, we shouldn't need to export linked
libraries to dependents. We should be explicit about this in
target_link_libraries, otherwise other targets that depend on these such
as sanitizers get repeated (and possibly even conflicting) dependencies.
Differential Revision: https://reviews.llvm.org/D57456
llvm-svn: 352688
When linking library dependencies, we shouldn't need to export linked
libraries to dependents. We should be explicit about this in
target_link_libraries, otherwise other targets that depend on these such
as sanitizers get repeated (and possibly even conflicting) dependencies.
Differential Revision: https://reviews.llvm.org/D57456
llvm-svn: 352654
This is useful when the static libunwind library is being linked into
shared libraries that may be used in with other shared libraries that
use different unwinder. We want to avoid avoid exporting libunwind
symbols in those cases. This achieved by a new CMake option which can be
enabled by libunwind vendors as needed.
The same CMake option has already been added to libc++ and libc++abi in
D55404 and D56026.
Differential Revision: https://reviews.llvm.org/D57107
llvm-svn: 352559
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Differential Revision: https://reviews.llvm.org/D57330
llvm-svn: 352514
Refactor the get_llvm_lit_path() logic to respect LLVM_EXTERNAL_LIT,
and require the fallback to be defined explicitly
as LLVM_DEFAULT_EXTERNAL_LIT. This fixes building libcxx standalone
after r346888.
The old logic was using LLVM_EXTERNAL_LIT both as user-defined cache
variable and an optional pre-definition of default value from caller
(e.g. libcxx). It included a hack to make this work by assigning
the value back and forth but it was fragile and stopped working
in libcxx.
The new logic is simpler and more transparent. Default value is
provided in a separate variable, and used only when user-specified
variable is empty (i.e. not overriden).
Differential Revision: https://reviews.llvm.org/D57282
llvm-svn: 352374
The check_library_exists CMake uses a custom symbol definition. This
is a problem when checking for C library symbols because Clang
recognizes many of them as builtins, and returns the
-Wbuiltin-requires-header (or -Wincompatible-library-redeclaration)
error. When building with -Werror which is the default, this causes
the check_library_exists check fail making the build think that C
library isn't available.
To avoid this issue, we should use a symbol that isn't recognized by
Clang and wouldn't cause the same issue. __libc_start_main seems like
reasonable choice that fits the bill.
Differential Revision: https://reviews.llvm.org/D57142
llvm-svn: 352341
This is useful when the static libc++abi library is being linked into
shared libraries that may be used in with other shared libraries that
use different C++ library. We want to avoid avoid exporting libc++abi
or libc++ symbols in those cases. This achieved by a new CMake option
which can be enabled by libc++abi vendors as needed.
Differential Revision: https://reviews.llvm.org/D56026
llvm-svn: 352017
When built within the llvm runtimes directory, the runtimes
CMakeLists.txt adds the same.
Differential Revision: https://reviews.llvm.org/D56979
llvm-svn: 351873
all missed!
Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.
llvm-svn: 351731
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.
Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.
I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.
This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.
Differential Revision: https://reviews.llvm.org/D56897
llvm-svn: 351631
With this patch, the copies of the files ItaniumDemangle.h,
StringView.h, and Utility.h are kept byte-for-byte in sync between
libcxxabi and llvm. All differences (namespaces, fallthrough, and
unreachable macros) are defined in each copies' DemanglerConfig.h.
This patch also adds a script to copy changes from libcxxabi
(cp-to-llvm.sh), and a README.txt explaining the situation.
Differential revision: https://reviews.llvm.org/D53538
llvm-svn: 351474
Summary:
std::bad_array_length was added by n3467, but this never made it into C++.
This commit removes the definition of std::bad_array_length from the headers
AND from the shared library. See the comments in the ABI changelog for details
about the ABI implications of this change.
Reviewers: mclow.lists, dexonsmith, howard.hinnant, EricWF
Subscribers: christof, jkorous, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54804
llvm-svn: 347903
Summary:
This (very specialized) function was added to enable an LLDB use case.
Now that a more generic interface (overriding of parser functions -
D52992) is available, and LLDB has been converted to use that (D54074),
the function is unused and can be removed.
Reviewers: erik.pilkington, sgraenitz, rsmith
Subscribers: mgorny, hiraditya, christof, libcxx-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D54893
llvm-svn: 347670
This is needed when cross-compiling for a different target since
CFLAGS may contain additional flags like -resource-dir which
change the location in which compiler-rt builtins are found.
Differential Revision: https://reviews.llvm.org/D54371
llvm-svn: 346820
Summary:
This silences the two -Wimplicit-fallthrough warnings clang finds in
ItaniumDemangle.h in libc++abi.
Clang does not have a GNU attribute spelling for this attribute, so this
is necessary.
I will commit the same change to the LLVM demangler soon.
Reviewers: EricWF, ldionne
Subscribers: christof, erik.pilkington, cfe-commits
Differential Revision: https://reviews.llvm.org/D53985
llvm-svn: 345870
Summary:
This uses CRTP (for performance reasons) to allow a user the override
demangler functions to implement custom parsing logic. The motivation
for this is LLDB, which needs to occasionaly modify the mangled names.
One such instance is already implemented via the TypeCallback member,
but this is very specific functionality which does not help with any
other use case. Currently we have a use case for modifying the
constructor flavours, which would require adding another callback. This
approach does not scale.
With CRTP, the user (LLDB) can override any function it needs without
any special support from the demangler library. After LLDB is ported to
use this instead of the TypeCallback mechanism, the callback can be
removed.
More context can be found in D50599.
Reviewers: erik.pilkington, rsmith
Subscribers: christof, ldionne, llvm-commits, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52992
llvm-svn: 344607
Summary:
I copied the sanitizer-related logic in libcxx/lib/CMakeLists.txt. In
the future, it would be great to avoid duplicating this logic in the
compiler, libc++ and libc++abi.
Reviewers: EricWF
Subscribers: mgorny, christof, dexonsmith, libcxx-commits, davide
Differential Revision: https://reviews.llvm.org/D53028
llvm-svn: 344191
Summary:
This was committed back in september (D51463), but it seems it never
made it into the libcxxabi copy.
The original commit message was:
The hash computed for an ArrayType was different when first constructed
versus when later profiled due to the constructor default argument, and
we were not tracking constructor / destructor variant as part of the
mangled name AST, leading to incorrect equivalences.
Reviewers: erik.pilkington, rsmith, EricWF
Subscribers: christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53063
llvm-svn: 344121
The "dynamic_cast error 2" error can apparently happen when the same
type (with RTTI) is defined in more than one translation unit, and
those translation units are linked together. This is technically an
ODR violation, but making the error message more obvious is still
helpful.
llvm-svn: 344052
This patch fixes a bug where exceptions in 32 bit builds
would be incorrectly aligned because malloc only provides 8 byte aligned
memory where 16 byte alignment is needed.
This patch makes libc++abi correctly use posix_memalign when it's
available. This requires defining _LIBCPP_BUILDING_LIBRARY so that
libc++ only defines _LIBCPP_HAS_NO_ALIGNED_ALLOCATION when libc doesn't
support it and not when aligned new/delete are disable for other
reasons.
This bug somehow made it into the 7.0 release, making it a regression.
Therefore this patch should be included in the next dot release.
llvm-svn: 342815
r340663 - Allow Allocator::make to make a node of a different type than that
requested.
r340664 - Add documentation comment to ForwardTemplateReference.
r340665 - Fix ExpandedSpecialSubstitution demangling for Sa and Sb.
r340670 - Allow demangler's node allocator to fail, and bail out of the entire
demangling process when it does.
llvm-svn: 340671
Move Itanium demangler implementation into a header file and add visitation support.
Summary:
This transforms the Itanium demangler into a generic reusable library that can
be used to build, traverse, and transform Itanium mangled name trees.
This is in preparation for adding a canonicalizing demangler, which
cannot live in the Demangle library for layering reasons. In order to
keep the diffs simpler, this patch moves more code to the new header
than is strictly necessary: in particular, all of the printLeft /
printRight implementations can be moved to the implementation file.
(And indeed we could make them non-virtual now if we wished, and remove
the vptr from Node.)
All nodes are now included in the Kind enumeration, rather than omitting
some of the Expr nodes, and the three different floating-point literal
node types now have distinct Kind values.
As a proof of concept for the visitation / matching mechanism, this
patch implements a Node dumping facility on top of it, replacing the
prior mechanism that produced the pretty-printed output rather than a
tree dump. Sample dump output:
FunctionEncoding(
NameType("int"),
NameWithTemplateArgs(
NestedName(
NameWithTemplateArgs(
NameType("A"),
TemplateArgs(
{NameType("B")})),
NameType("f")),
TemplateArgs(
{NameType("int")})),
{},
<null>,
QualConst, FunctionRefQual::FrefQualLValue)
As a next step, it would make sense to move the LLVM high-level interface to
the demangler (the itaniumDemangler function and ItaniumPartialDemangler class)
into the Support library, and implement them in terms of the Demangle library.
This would allow the libc++abi demangler implementation to be an identical copy
of the llvm Demangle library, and would allow the LLVM implementation to reuse
LLVM components such as llvm::BumpPtrAllocator, but we'll need to decide how to
coordinate that with the MS ABI demangler, so I'm not doing that in this patch.
No functionality change intended other than the behavior of dump().
Reviewers: erik.pilkington, zturner, chandlerc, dlj
Subscribers: aheejin, llvm-commits
Differential Revision: https://reviews.llvm.org/D50930
llvm-svn: 340207
This function calls a callback whenever a <type> is parsed.
This is necessary to implement FindAlternateFunctionManglings in LLDB, which
uses a similar hack in FastDemangle. Once that function has been updated to use
this version, FastDemangle can finally be removed.
Differential revision: https://reviews.llvm.org/D50586
llvm-svn: 339580
Stack overflow on invalid. While collapsing references, we were skipping over a
cycle check in ForwardTemplateReference leading to a stack overflow. This commit
fixes the problem by duplicating the cycle check in ReferenceType.
llvm-svn: 338190
Summary:
rL337867 introduced two new cmake_dependent_option options:
- LIBCXXABI_INSTALL_STATIC_LIBRARY
- LIBCXXABI_INSTALL_SHARED_LIBRARY
They depend on LIBCXXABI_ENABLE_STATIC and LIBCXXABI_ENABLE_SHARED
and so therefore need to (it seems) come after the declaration of
these two options.
Subscribers: mgorny, aheejin, christof, ldionne, cfe-commits
Differential Revision: https://reviews.llvm.org/D49825
llvm-svn: 337982
Currently it's only possible to control whether shared or static library
build of libc++, libc++abi and libunwind is enabled or disabled and
whether to install everything we've built or not. However, it'd be
useful to have more fine grained control, e.g. when static libraries are
merged together into libc++.a we don't need to install libc++abi.a and
libunwind.a. This change adds this option.
Differential Revision: https://reviews.llvm.org/D49573
llvm-svn: 337867
We really should set *status to memory_alloc_failure, but we need to refactor
the demangler a bit to properly propagate the failure up the stack. Until then,
its better to explicitly terminate then rely on a null dereference crash.
rdar://31240372
llvm-svn: 337759
This allows handling SEH based exceptions, with unwind functions
provided by libgcc.
Differential Revision: https://reviews.llvm.org/D49638
llvm-svn: 337754
Currently it's possible to select whether to statically link unwinder
or the C++ ABI library, but this option applies to both the shared
and static library. However, in some scenarios it may be desirable to
only statically link unwinder and C++ ABI library into static C++
library since for shared C++ library we can rely on dynamic linking
and linker scripts. This change enables selectively enabling or
disabling statically linking only to shared or static library.
Differential Revision: https://reviews.llvm.org/D49502
llvm-svn: 337668
ItaniumDemangle had a small NFC refactor to make some of its
code reusable by the newly added Microsoft demangler. To keep
the libcxxabi demangler as close as possible to the master copy
this refactor is being merged over.
Differential Revision: https://reviews.llvm.org/D49575
llvm-svn: 337582
Do not use LLVM_RUNTIMES_LIBDIR_SUFFIX variable which is an internal
variable used by the runtimes build from individual runtimes, instead
set per-runtime librarhy directory suffix variable which is necessary
for the sanitized runtimes build to install libraries into correct
location.
Differential Revision: https://reviews.llvm.org/D49121
llvm-svn: 336713
The alignment specified by a constant for the field
`BumpPointerAllocator::InitialBuffer` exceeded the alignment
guaranteed by `malloc` and `new` on Windows. This change set
the alignment value to that of `long double`, which is defined
by the used platform.
It fixes https://bugs.llvm.org/show_bug.cgi?id=37944.
Differential Revision: https://reviews.llvm.org/D48889
llvm-svn: 336312
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
Eric Fiselier