[Openmp-commits] [libcxx] [compiler-rt] [mlir] [libcxxabi] [clang] [lld] [openmp] [llvm] [runtimes] Use LLVM libunwind from libc++abi by default (PR #77687)

[Ryan Prichard via Openmp-commits]

================
@@ -22,6 +22,9 @@ set(LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "")
 set(LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY ON CACHE BOOL "")
 set(LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "")
 
+# Android uses its own unwinder library
+set(LIBCXXABI_USE_LLVM_UNWINDER OFF CACHE BOOL "")
----------------
rprichard wrote:

The Android NDK currently sources all of libunwind, libc++abi, and libc++ from the same LLVM commit, so maybe it's better to build the unwinder library at the same time as libc++.

OTOH, Android's libc.so exports libunwind's EH API as of API 30 (Android 11), so eventually the NDK might be using an unwinder that's from a much older LLVM commit. It'll be a long time before the NDK targets API 30 as a minimum.

IIRC, when I last looked at the Linux libc++ CI tests (i.e. non-Android), the LLVM libunwind was built in the same runtimes CMake invocation as libc++, but the result wasn't actually used or tested. When I set up Android CI testing, I initially had it build libunwind as part of the CI testing, but I wanted the result to resemble what the NDK actually ships, which required a separate step for libunwind (and patching the result into a new resource dir) (see https://reviews.llvm.org/D139147?id=549856, search for "Build libunwind.a"). This patching was dropped in favor of using a libunwind.a from an Android Clang build.


https://github.com/llvm/llvm-project/pull/77687