When exceptions are disabled, avoid their processing altogether.
This avoids pulling in the depenency on demangler significantly
reducing binary size when statically linking against libc++abi
built without exception support.

Differential Revision: https://reviews.llvm.org/D64191

llvm-svn: 365944

llvm-svn: 364677

Reviewers: EricWF

Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D63345

llvm-svn: 364586

llvm-svn: 363752

Summary: I'm pretty sure it's not used anymore, at least it isn't used at Apple.

Reviewers: EricWF, Bigcheese

Subscribers: christof, jkorous, dexonsmith, jfb, mstorsjo, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D63297

llvm-svn: 363737

llvm-svn: 362983

ar doesn't produce the correct results when used for linking static
archives on Apple platforms, so instead use libtool -static which is
the official way to build static archives on those platforms.

Differential Revision: https://reviews.llvm.org/D62770

llvm-svn: 362311

These seemed to have been used in the past but were since removed
by the add_compile_flags_if_supported functions that combine these
these checks and adding the flag, but the original checks were never
removed.

Differential Revision: https://reviews.llvm.org/D62566

llvm-svn: 362058

This is a follow up to r362055, we need -Wunknown-pragmas otherwise
the check is going to succeed it the pragma isn't supported.

llvm-svn: 362057

This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is Clang, but older Clang versions don't support this pragma so
we need to check first if it's supported before using it.

llvm-svn: 362055

As of r360984, LLD supports dependent libraries feature for ELF.
libunwind, libc++abi and libc++ have library dependencies: libdl librt
and libpthread, which means that when libunwind and libc++ are being
statically linked (using -static-libstdc++ flag), user has to manually
specify -ldl -lpthread which is onerous.

This change includes the lib pragma to specify the library dependencies
directly in the source that uses those libraries. This doesn't make any
difference when using linkers that don't support dependent libraries.
However, when using LLD that has dependent libraries feature, users no
longer have to manually specifying library dependencies when using
static linking, linker will pick the library automatically.

Differential Revision: https://reviews.llvm.org/D62090

llvm-svn: 362048

The libc++ typeinfo implementation is being improved to better
handle non-merged type names.

This patch takes advantage of that more correct behavior by delegating
to std::type_infos default operator== instead of doing pointer equality
ourselves.

However, libc++ still expects unique RTTI by default, and so we
should still fall back to strcmp when explicitly requested.

llvm-svn: 361916

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/c++ and include/c++ directories, leaving resource directory
only for compiler-rt runtimes and Clang builtin headers.

Differential Revision: https://reviews.llvm.org/D59168

llvm-svn: 361432

rdar://problem/49864414

llvm-svn: 361039

llvm-svn: 360944

llvm-svn: 360142

When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.

Differential Revision: https://reviews.llvm.org/D61572

llvm-svn: 360004

This change introduces support for building libcxxabi. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.

We only support two stage build at the moment.

Differential Revision: https://reviews.llvm.org/D60372

llvm-svn: 359805

The threaded cxa guard test attempted to test multithreaded waiting
by lining up a bunch of threads at a held init lock and releasing them.
The test initially wanted each thread to observe the lock being held,
but some threads may arive too late.

This patch cleans up the test and relaxes the restrictions.

llvm-svn: 359785

There's no need for the demangling bits to depend on libc++ internals,
in the same way they don't when compiled as part of LLVM.

llvm-svn: 359534

llvm-svn: 359415

The error is:

libcxxabi/src/cxa_guard_impl.h: In instantiation of ‘__cxxabiv1::{anonymous}::LibcppMutex __cxxabiv1::{anonymous}::GlobalStatic<__cxxabiv1::{anonymous}::LibcppMutex>::instance’:
libcxxabi/src/cxa_guard_impl.h:529:62:   required from here
libcxxabi/src/cxa_guard_impl.h:510:23: error: ‘__cxxabiv1::{anonymous}::LibcppMutex __cxxabiv1::{anonymous}::GlobalStatic<__cxxabiv1::{anonymous}::LibcppMutex>::instance’ has incomplete type
 _LIBCPP_SAFE_STATIC T GlobalStatic<T>::instance = {};
                       ^

llvm-svn: 359175

* Add TSAN annotations around the futex syscalls.
* Test that the futex syscall wrappers actually work.
* Fix bad names.

llvm-svn: 359069

llvm-svn: 359065

This patch does three main things:
  (1) It re-writes the cxa guard implementation to make it testable.
  (2) Adds support for recursive init detection on non-apple platforms.
  (3) It adds a futex based implementation.

The futex based implementation locks and notifies on a per-object basis, unlike the
current implementation which uses a global lock for all objects. Once this patch settles
I'll turn it on by default when supported.

llvm-svn: 359060

Otherwise, we don't seem to get the DYLD_LIBRARY_PATH set up correctly
and the tests are run against the system libc++abi dylib.

llvm-svn: 358937

Summary:
Ensure we re-export __cxa_throw_bad_array_new_length and
__cxa_uncaught_exceptions from libc++, since they are now
provided by libc++abi.

Doing this allows us to stop linking explicitly against libc++abi in
the libc++abi tests, since libc++ re-exports all the necessary symbols.
However, there is one caveat to that. We don't want libc++ to re-export
__cxa_uncaught_exception (the singular form), since it's only provided
for backwards compatibility. Hence, for the single test where we check
this backwards compatibility, we explicitly link against libc++abi.

PR27405
PR22654

Reviewers: EricWF

Subscribers: christof, jkorous, dexonsmith, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D60424

llvm-svn: 358690

On ARM the hand-rolled check causes a call to __aeabi_uidiv,
which we may not have a definition for.

Using the builtin avoids the generation of any library call.

llvm-svn: 358195

Those are now hosted on GitHub.

rdar://problem/36557462

llvm-svn: 358191

Summary:
The goal is to use a descriptive name for this feature, instead of just
using __arm__.

Reviewers: EricWF

Subscribers: javed.absar, kristof.beyls, christof, jkorous, dexonsmith, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D60520

llvm-svn: 358106

This reverts commit r357944 and r357949.

These changes failed to account for the fact that
the guard object is under aligned for atomic operations
on 32 bit platforms (It's aligned to 4 bytes but we require 8).

llvm-svn: 357958

cxa_guard_abort should still broadcast on exit.

llvm-svn: 357956

The INIT_COMPLETE write now writes to the entire guard object
instead of just one byte.

llvm-svn: 357949

The read of the guard variable by the caller is atomic,
and doesn't happen under a mutex.

Our internal reads and writes were non-atomic, because they happened
under a mutex.

The writes should always be atomic since they can be observed outside
of the lock.

Making the reads atomic is not strictly necessary under the current
global mutex approach, but will be under implementations that use a
futex (which I plan to land shortly). However, they should add little
additional cost.

llvm-svn: 357944

llvm-svn: 357814

This patch is a part of a series of patches to cleanup
our implementation of __cxa_acquire et al. No functionality
change was intended.

This patch does two primary things.

It introduces the GuardObject class to abstract the reading
and writing to the guard object. In future, it will be used
to ensure atomic accesses are used when needed.

It also introduces the GuardValue class used to represent
values of the guard object. It is an abstraction to access
and write to the various different bits of a guard.

llvm-svn: 357804

This patch is a part of a series of cleanups to cxa_guard.cpp.
It should introduce no functionality change.

This patch refactors the use of the global mutex and condvar into
a RAII lock guard class. This improves correctness (since unlocks can't
be forgotten). It also allows the unification of the non-threading and
threading implementations.

llvm-svn: 357669

This patch is part of a series of cleanups to cxa_guard.cpp.
It should have no functionality change.

llvm-svn: 357668

These are variant 4, cf
https://github.com/gcc-mirror/gcc/blob/master/gcc/cp/mangle.c#L1851
https://github.com/gcc-mirror/gcc/blob/master/gcc/cp/mangle.c#L1880
and gcc seems to sometimes emit them still.

Differential Revision: https://reviews.llvm.org/D60229

llvm-svn: 357645

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