[libcxx-commits] [PATCH] D150897: [runtimes] Use libunwind from libc++ and libc++abi by default

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a comment.

Thanks everyone for chiming in, this is exactly what I was looking for!

In D150897#4354210 <https://reviews.llvm.org/D150897#4354210>, @manojgupta wrote:

> GCC's libgcc_s/libgcc and llvm's libunwind are not ABI compatible, the code will compile/link but will crash at runtime for calls to functions like backtrace() because functions from libunwind and libgcc will get intermingled. So this is a risky change for the users. I'd strongly advise to make a note of this is release notes.

Do you mean that on platforms where system libraries are using `libgcc_s` as the unwinder by default, trying to then use libc++ (built against LLVM's libunwind) e.g. from a LLVM release would create these ABI issues? So essentially, a vendor shipping the LLVM toolchain on such a platform would want to *not* ship libunwind (and make sure that libc++ uses the system provided unwinder) for the sake of interoperability with the base system?

I think that makes sense, and indeed that would then merit a release note for sure.

What I would then suggest is:

1. We make this change with a release note
2. We introduce a new CI job called "with the system unwinder"
3. In a separate change, I could refactor the way we select the unwinder to match what we do for libc++abi, i.e. we would have `LIBCXXABI_UNWINDER_LIBRARY="libunwind|gcc|whatever"`

That way, we'd ship a LLVM toolchain that uses its own stuff by default, but a vendor would still be free to select a different unwinder library. That would make the situation with the unwinder library choice consistent with how we handle picking the ABI library.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150897/new/

https://reviews.llvm.org/D150897