llvm-capstone/libcxx/cmake/caches
Louis Dionne 8f90e6937a
[runtimes] Use LLVM libunwind from libc++abi by default (#77687)
I recently came across LIBCXXABI_USE_LLVM_UNWINDER and was surprised to
notice it was disabled by default. Since we build libunwind by default
and ship it in the LLVM toolchain, it would seem to make sense that
libc++ and libc++abi rely on libunwind for unwinding instead of using
the system-provided unwinding library (if any).

Most importantly, using the system unwinder implies that libc++abi is
ABI compatible with that system unwinder, which is not necessarily the
case. Hence, it makes a lot more sense to instead default to using the
known-to-be-compatible LLVM unwinder, and let vendors manually select a
different unwinder if desired.

As a follow-up change, we should probably apply the same default to
compiler-rt.

Differential Revision: https://reviews.llvm.org/D150897
Fixes #77662
rdar://120801778
2024-01-11 10:13:21 -05:00
..
AArch64.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
AIX.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
AndroidNDK.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
Apple.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
Armv7Arm.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
Armv7M-picolibc.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
Armv7Thumb-no-exceptions.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
Armv8Arm.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
Armv8Thumb-no-exceptions.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
FreeBSD.cmake
Generic-abi-unstable.cmake
Generic-asan.cmake
Generic-cxx03.cmake
Generic-cxx11.cmake
Generic-cxx14.cmake
Generic-cxx17.cmake
Generic-cxx20.cmake
Generic-cxx23.cmake
Generic-cxx26.cmake
Generic-hardening-mode-debug.cmake
Generic-hardening-mode-extensive.cmake
Generic-hardening-mode-fast-with-abi-breaks.cmake
Generic-hardening-mode-fast.cmake
Generic-merged.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
Generic-modules-lsv.cmake
Generic-modules.cmake
Generic-msan.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
Generic-no-exceptions.cmake
Generic-no-experimental.cmake
Generic-no-filesystem.cmake
Generic-no-localization.cmake
Generic-no-random_device.cmake
Generic-no-rtti.cmake [libc++][CI] Tests the no RTTI configuration. (#65518) 2023-12-12 17:11:53 +01:00
Generic-no-threads.cmake
Generic-no-tzdb.cmake [libc++][CI] Enable modules in no TZDB build. (#75704) 2023-12-18 10:27:13 -05:00
Generic-no-unicode.cmake
Generic-no-wide-characters.cmake
Generic-optimized-speed.cmake [libc++] Allow running the test suite with optimizations (#68753) 2024-01-09 10:39:14 -05:00
Generic-static.cmake
Generic-tsan.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
Generic-ubsan.cmake
MinGW.cmake [runtimes] Use LLVM libunwind from libc++abi by default (#77687) 2024-01-11 10:13:21 -05:00
README.md
s390x32-ibm-zos-ascii.cmake
s390x32-ibm-zos.cmake
s390x-ibm-zos-ascii.cmake
s390x-ibm-zos.cmake

libc++ / libc++abi configuration caches

This directory contains CMake caches for the supported configurations of libc++. Some of the configurations are specific to a vendor, others are generic and not tied to any vendor.

While we won't explicitly work to break configurations not listed here, any configuration not listed here is not explicitly supported. If you use or ship libc++ under a configuration not listed here, you should work with the libc++ maintainers to make it into a supported configuration and add it here.

Similarly, adding any new configuration that's not already covered must be discussed with the libc++ maintainers as it entails a maintenance burden.