aboutsummaryrefslogtreecommitdiff
path: root/libcxxabi
AgeCommit message (Collapse)AuthorFilesLines
2019-07-19Drop svn version suffix.Hans Wennborg1-1/+1
llvm-svn: 366548
2019-07-12[libcxxabi] Don't process exceptions in cxa_handlers when they're disabledPetr Hosek3-1/+7
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
2019-06-28[demangle] Support for C++2a char8_tErik Pilkington2-0/+7
llvm-svn: 364677
2019-06-27[libcxxabi] Use an explicit list to export symbols from the dylibLouis Dionne5-0/+416
Reviewers: EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D63345 llvm-svn: 364586
2019-06-18[demangle] Special case clang's creative mangling of __uuidof expressions.Erik Pilkington2-0/+34
llvm-svn: 363752
2019-06-18[libcxxabi] Remove the unused buildit scriptLouis Dionne1-99/+0
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
2019-06-10[demangle] Vendor extended types shouldn't be considered substitution candidatesErik Pilkington2-2/+9
llvm-svn: 362983
2019-06-02[libcxx] Use libtool when merging archives on Apple platformsPetr Hosek1-0/+5
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
2019-05-30[libcxx][libcxxabi] Remove the unused CMake checksPetr Hosek1-32/+1
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
2019-05-30[runtimes] Use -Wunknown-pragmas for the pragma checkPetr Hosek1-0/+4
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
2019-05-30[runtimes] Check if pragma comment(lib, ...) is supported firstPetr Hosek6-3/+20
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
2019-05-30[runtimes] Support ELF dependent libraries featurePetr Hosek3-0/+16
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
2019-05-29Update private_typeinfo's `is_equal` implementation after r361913Eric Fiselier1-7/+5
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
2019-05-22[runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and ↵Petr Hosek2-6/+11
include/c++ 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
2019-05-17[libcxxabi] Add a test for invalid assumptions on the alignment of exceptionsLouis Dionne1-0/+34
rdar://problem/49864414 llvm-svn: 361039
2019-05-16XFAIL test for new GCC versionEric Fiselier1-1/+1
llvm-svn: 360944
2019-05-07minor cmake formatting style fixNico Weber1-1/+3
llvm-svn: 360142
2019-05-06[libcxxabi] Don't use -fvisibility-global-new-delete-hidden when not ↵Petr Hosek1-1/+6
defining them 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
2019-05-02[gn] Support for building libcxxabiPetr Hosek2-7/+11
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
2019-05-02Attempt to fix flaky tests.Eric Fiselier1-188/+149
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
2019-04-30Update DemangleConfig.h to better mangle LLVM's version.Eric Fiselier1-12/+68
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
2019-04-29Remove XFail for new GCC. They fixed itEric Fiselier1-1/+1
llvm-svn: 359415
2019-04-25Fix compilation error with -DLIBCXXABI_ENABLE_THREADS=OFFMichael Platings1-0/+3
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
2019-04-24Cleanup new cxa guard implementation.Eric Fiselier3-8/+58
* Add TSAN annotations around the futex syscalls. * Test that the futex syscall wrappers actually work. * Fix bad names. llvm-svn: 359069
2019-04-24Work around GCC test failure.Eric Fiselier1-2/+2
llvm-svn: 359065
2019-04-24Rewrite cxa guard implementation.Eric Fiselier5-263/+1127
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
2019-04-23[libc++abi] Don't use a .sh.cpp test for uncaught_exceptionLouis Dionne1-6/+0
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
2019-04-18[libc++] Make sure we re-export some missing libc++abi symbols from libc++Louis Dionne2-16/+40
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
2019-04-11Fix PR41465 - Use __builtin_mul_overflow instead of hand-rolled check.Eric Fiselier2-4/+31
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
2019-04-11[NFC] Correct outdated links to the Itanium C++ ABI documentationLouis Dionne8-8/+8
Those are now hosted on GitHub. rdar://problem/36557462 llvm-svn: 358191
2019-04-10[libc++abi] Create a macro for the 32 bit guard setting on ARM platformsLouis Dionne3-11/+15
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
2019-04-08Revert "Make reads and writes of the guard variable atomic."Eric Fiselier1-33/+19
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
2019-04-08Fix incorrect change during refactoring.Eric Fiselier1-1/+1
cxa_guard_abort should still broadcast on exit. llvm-svn: 357956
2019-04-08Remove unneeded write in __cxa_guard_release.Eric Fiselier1-1/+0
The INIT_COMPLETE write now writes to the entire guard object instead of just one byte. llvm-svn: 357949
2019-04-08Make reads and writes of the guard variable atomic.Eric Fiselier1-19/+34
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
2019-04-05Fix PR41395 - __cxa_vec_new may overflow in allocation size calculation.Eric Fiselier2-13/+165
llvm-svn: 357814
2019-04-05Further refactor cxa_guard.cppEric Fiselier1-144/+176
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
2019-04-04Create RAII lock guard for global initialization lock.Eric Fiselier1-81/+94
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
2019-04-04Always use is_initialized and set_initialized in cxa_guard.cppEric Fiselier1-16/+8
This patch is part of a series of cleanups to cxa_guard.cpp. It should have no functionality change. llvm-svn: 357668
2019-04-03llvm-cxxfilt: Demangle gcc "old-style unified" ctors and dtorsNico Weber2-7/+16
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
2019-04-03[libc++abi] Do not share an object library to create the static/shared librariesPetr Hosek1-59/+39
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
2019-04-03[libc++abi] Add LIBCXXABI_ENABLE_PIC cmake optionSam Clegg2-1/+5
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
2019-04-03[libc++abi] Actually set POSITION_INDEPENDENT_CODE when building shared librarySam Clegg1-1/+3
This is a bug fix from https://reviews.llvm.org/D60005. Differential Revision: https://reviews.llvm.org/D60158 llvm-svn: 357550
2019-03-29[libc++abi] Don't set POSITION_INDEPENDENT_CODE when building static librarySam Clegg1-12/+7
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
2019-03-08Revert "[runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/"Matthew Voss2-11/+6
This broke the windows bots. This reverts commit 28302c66d2586074f77497d5dc4eac7182b679e0. llvm-svn: 355725
2019-03-08[runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/Petr Hosek2-6/+11
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
2019-03-01[libc++abi] Specify unwind lib before other system libraries when linkingLouis Dionne1-2/+2
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
2019-02-18[libcxxabi][CMake] Drop unused HandleOutOfTreeLLVM includePetr Hosek1-3/+0
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
2019-02-17[compiler-rt] Build custom libcxx with libcxxabiJonas Hahnfeld1-1/+1
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
2019-02-12[CMake] Avoid passing -rtlib=compiler-rt when using compiler-rtPetr Hosek1-4/+0
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
generated by cgit v1.1 at 2024-11-13 12:27:54 +0000