This allows us to detect whether we're being compiled with LLVM's libunwind
more easily, without CMake having to set explicit variables.
As discussed in https://llvm.org/D119538.
Differential D121015
[libunwind] Add a _LIBUNWIND_VERSION macro ldionne on Mar 4 2022, 11:36 AM. Authored by
Details
This allows us to detect whether we're being compiled with LLVM's libunwind As discussed in https://llvm.org/D119538.
Diff Detail
Event TimelineComment Actions I think the code would be inconsistent with surrounding code if I listened to them, so I'm tempted to ignore them instead. LMK if you disagree. @mgorny Is this patch OK with you? Can you test it locally? I suspect that, in its current form, it's not going to quite work for you unless you have basically ToT libunwind headers installed on your system, right? Comment Actions I'm sorry, my replacement PSU just arrived today and I'm slowly catching up with everything. I presume we don't need to worry about backwards compatibility, so LGTM. Comment Actions No worries. If you think this works for your use case, then I think this should be good to go. I verified and we do take that code path when we build the runtimes with LIBCXXABI_USE_LLVM_UNWINDER. However, upon thinking about it again, I think it's safer to add a temporary workaround to detect LLVM's libunwind in libc++abi for a couple of releases, until we can assume that libunwind headers from LLVM 15 (or newer) are being used to build libc++abi. That should take care of folks who might be building libc++abi against an out-of-sync LLVM libunwind (e.g. as part of a SDK or a system-provided libunwind). I'll add a workaround and you folks can tell me what you think -- sorry for the churn. Comment Actions Add workaround for building libc++abi against older libunwind. What do people think about this? Comment Actions I'll ship this since it should be strictly safer than the previous version of the patch. |
clang-format: please reformat the code