Errmm.... :( What motivated this? (something on Darwin, I guess?) Is there a reason to change this for LLVM 7 in particular? (should other versions be changed?) libc++abi most certainly can make use of LLVM's unwinder, take a look at the source if you're curious/interested. Perhaps we were failing to configure the build system properly? Is this removal useful in any observable way (fixes something?) or was it suggested as a cleanup after noticing it not having the intended behavior? Managing to convince all the LLVM bits to work properly and with sane configuration is a bit difficult when building each component individually... The real question is whether it's desired/useful to use LLVM's libunwind on each platform, and then make changes to ensure that we're building things accordingly. Until then it is unclear if the issue is we shouldn't be trying to use LLVM's unwinder (as this PR assumes) or if we /should/ be using LLVM's unwinder but are failing to do so (for whatever reason). Anyone have input/experience re:what Nixpkgs's libc++abi unwinder "should" be? (perhaps platform-specific?) Also: https://clang.llvm.org/docs/Toolchain.html#unwind-library One additional reason to prefer LLVM's unwinder: producing toolchain free of GCC bits, an especially important accomplishment given Nixpkgs' bug regarding ancient libgcc_s from bootstrap propagating everywhere (but even if that were fixed, a gcc-free LLVM is a popular goal for other reasons, and something I've certainly found useful).