summaryrefslogtreecommitdiffstats
path: root/libcxxabi
Commit message (Collapse)AuthorAgeFilesLines
...
* [runtimes] Check if pragma comment(lib, ...) is supported firstPetr Hosek2019-05-306-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
* [runtimes] Support ELF dependent libraries featurePetr Hosek2019-05-303-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
* Update private_typeinfo's `is_equal` implementation after r361913Eric Fiselier2019-05-291-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
* [runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and ↵Petr Hosek2019-05-222-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
* [libcxxabi] Add a test for invalid assumptions on the alignment of exceptionsLouis Dionne2019-05-171-0/+34
| | | | | | rdar://problem/49864414 llvm-svn: 361039
* XFAIL test for new GCC versionEric Fiselier2019-05-161-1/+1
| | | | llvm-svn: 360944
* minor cmake formatting style fixNico Weber2019-05-071-1/+3
| | | | llvm-svn: 360142
* [libcxxabi] Don't use -fvisibility-global-new-delete-hidden when not ↵Petr Hosek2019-05-061-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
* [gn] Support for building libcxxabiPetr Hosek2019-05-022-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
* Attempt to fix flaky tests.Eric Fiselier2019-05-021-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
* Update DemangleConfig.h to better mangle LLVM's version.Eric Fiselier2019-04-301-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
* Remove XFail for new GCC. They fixed itEric Fiselier2019-04-291-1/+1
| | | | llvm-svn: 359415
* Fix compilation error with -DLIBCXXABI_ENABLE_THREADS=OFFMichael Platings2019-04-251-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
* Cleanup new cxa guard implementation.Eric Fiselier2019-04-243-8/+58
| | | | | | | | * Add TSAN annotations around the futex syscalls. * Test that the futex syscall wrappers actually work. * Fix bad names. llvm-svn: 359069
* Work around GCC test failure.Eric Fiselier2019-04-241-2/+2
| | | | llvm-svn: 359065
* Rewrite cxa guard implementation.Eric Fiselier2019-04-245-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
* [libc++abi] Don't use a .sh.cpp test for uncaught_exceptionLouis Dionne2019-04-231-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
* [libc++] Make sure we re-export some missing libc++abi symbols from libc++Louis Dionne2019-04-182-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
* Fix PR41465 - Use __builtin_mul_overflow instead of hand-rolled check.Eric Fiselier2019-04-112-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
* [NFC] Correct outdated links to the Itanium C++ ABI documentationLouis Dionne2019-04-118-8/+8
| | | | | | | | Those are now hosted on GitHub. rdar://problem/36557462 llvm-svn: 358191
* [libc++abi] Create a macro for the 32 bit guard setting on ARM platformsLouis Dionne2019-04-103-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
* Revert "Make reads and writes of the guard variable atomic."Eric Fiselier2019-04-081-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
* Fix incorrect change during refactoring.Eric Fiselier2019-04-081-1/+1
| | | | | | cxa_guard_abort should still broadcast on exit. llvm-svn: 357956
* Remove unneeded write in __cxa_guard_release.Eric Fiselier2019-04-081-1/+0
| | | | | | | The INIT_COMPLETE write now writes to the entire guard object instead of just one byte. llvm-svn: 357949
* Make reads and writes of the guard variable atomic.Eric Fiselier2019-04-081-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
* Fix PR41395 - __cxa_vec_new may overflow in allocation size calculation.Eric Fiselier2019-04-052-13/+165
| | | | llvm-svn: 357814
* Further refactor cxa_guard.cppEric Fiselier2019-04-051-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
* Create RAII lock guard for global initialization lock.Eric Fiselier2019-04-041-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
* Always use is_initialized and set_initialized in cxa_guard.cppEric Fiselier2019-04-041-16/+8
| | | | | | | This patch is part of a series of cleanups to cxa_guard.cpp. It should have no functionality change. llvm-svn: 357668
* llvm-cxxfilt: Demangle gcc "old-style unified" ctors and dtorsNico Weber2019-04-032-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
* [libc++abi] Do not share an object library to create the static/shared librariesPetr Hosek2019-04-031-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
* [libc++abi] Add LIBCXXABI_ENABLE_PIC cmake optionSam Clegg2019-04-032-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
* [libc++abi] Actually set POSITION_INDEPENDENT_CODE when building shared librarySam Clegg2019-04-031-1/+3
| | | | | | | | This is a bug fix from https://reviews.llvm.org/D60005. Differential Revision: https://reviews.llvm.org/D60158 llvm-svn: 357550
* [libc++abi] Don't set POSITION_INDEPENDENT_CODE when building static librarySam Clegg2019-03-291-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
* Revert "[runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/"Matthew Voss2019-03-082-11/+6
| | | | | | | | This broke the windows bots. This reverts commit 28302c66d2586074f77497d5dc4eac7182b679e0. llvm-svn: 355725
* [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/Petr Hosek2019-03-082-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
* [libc++abi] Specify unwind lib before other system libraries when linkingLouis Dionne2019-03-011-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
* [libcxxabi][CMake] Drop unused HandleOutOfTreeLLVM includePetr Hosek2019-02-181-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
* [compiler-rt] Build custom libcxx with libcxxabiJonas Hahnfeld2019-02-171-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
* [CMake] Avoid passing -rtlib=compiler-rt when using compiler-rtPetr Hosek2019-02-121-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
* [CMake] Support compiler-rt builtins library in testsPetr Hosek2019-02-051-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* [CMake] Update lit test configurationPetr Hosek2019-02-052-7/+9
| | | | | | | | | 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] Support CMake variables for setting target, sysroot and toolchainPetr Hosek2019-02-042-7/+17
| | | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Use correct visibility for linked libraries in CMakePetr Hosek2019-01-301-2/+2
| | | | | | | | | | | 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
* Revert "[CMake] Use correct visibility for linked libraries in CMake"Petr Hosek2019-01-301-2/+2
| | | | | | This reverts commit r352654: this broke libcxx and sanitizer bots. llvm-svn: 352658
* [CMake] Use correct visibility for linked libraries in CMakePetr Hosek2019-01-301-2/+2
| | | | | | | | | | | 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
* [libunwind] Support building hermetic static libraryPetr Hosek2019-01-291-1/+5
| | | | | | | | | | | | | | | 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
* Adjust documentation for git migration.James Y Knight2019-01-291-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[CMake] Use __libc_start_main rather than fopen when checking for C ↵Petr Hosek2019-01-281-1/+1
| | | | | | | | | library" This reverts commit r352341: it broke the build on macOS which doesn't seem to provide __libc_start_main in its C library. llvm-svn: 352411
* [cmake] Fix get_llvm_lit_path() to respect LLVM_EXTERNAL_LIT alwaysMichal Gorny2019-01-281-1/+1
| | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud