[llvm] [llvm][cmake] Try LLVM libunwind when frame registration is unavailable (PR #112087)
via llvm-commits
llvm-commits at lists.llvm.org
Fri Nov 1 12:23:36 PDT 2024
================
@@ -272,6 +272,13 @@ endif()
check_symbol_exists(__register_frame "${CMAKE_CURRENT_LIST_DIR}/unwind.h" HAVE_REGISTER_FRAME)
check_symbol_exists(__deregister_frame "${CMAKE_CURRENT_LIST_DIR}/unwind.h" HAVE_DEREGISTER_FRAME)
check_symbol_exists(__unw_add_dynamic_fde "${CMAKE_CURRENT_LIST_DIR}/unwind.h" HAVE_UNW_ADD_DYNAMIC_FDE)
+if (NOT (HAVE_REGISTER_FRAME OR HAVE_DEREGISTER_FRAME OR HAVE_UNW_ADD_DYNAMIC_FDE))
+ check_library_exists(unwind __unw_add_dynamic_fde "" HAVE_LLVM_LIBUNWIND)
+ if (HAVE_LLVM_LIBUNWIND)
+ list(APPEND CMAKE_REQUIRED_LIBRARIES "unwind")
+ set(HAVE_UNW_ADD_DYNAMIC_FDE 1)
+ endif ()
+endif ()
----------------
ziyao233 wrote:
> > I dont think it's a problem.
>
> So this _would_ cause all of these tools to explicitly link libunwind?
Yes.
> That seems like a significant change.
>
> > If __register_frame symbols aren't available without linking to external libraries, we're definitely working with compiler-rt & libcxx & libcxxabi, which already require linking to libunwind.
>
> That's surprising to me. I thought libcxx / libcxxabi could be mixed with the gcc unwinder, but I've never actually tried (I'm usually developing on Darwin where libunwind is the system unwinder).
>
> Is it possible to mix libunwind with other (non libcxx) c++ standard libraries?
My statement is partially wrong, sorry.
Here the main problem isn't underlinking, but we don't use `-lunwind` when checking for LLVM libunwind symbols, which are contained in an external library, resulting in misdetection.
A better solution may be
- Detect whether gcc-style unwinding symbols presents by default, if not we assume LLVM libunwind (OrcJIT supports only these two unwinders)
- If we aren't working with gcc unwinder, link libLLVM to libunwind explicitly, for completeness
Linking libunwind only for `clang-repl`, `lli` and `llvm-jitlink` isn't enough, since it's actually LLVM OrcJIT depending on the unwinder, other programs like mesa use LLVM OrcJIT as well.
What do you think about this solution? Thanks for your patience.
https://github.com/llvm/llvm-project/pull/112087
More information about the llvm-commits
mailing list