[PATCH] D15440: [libc++abi] Use libgcc and libgcc_s to provide _Unwind symbols instead of libgcc_eh.a

Saleem Abdulrasool via cfe-commits cfe-commits at lists.llvm.org
Fri Dec 11 08:26:56 PST 2015


compnerd added inline comments.

================
Comment at: cmake/config-ix.cmake:45
@@ -44,3 +44,3 @@
 check_library_exists(pthread pthread_once "" LIBCXXABI_HAS_PTHREAD_LIB)
-check_library_exists(gcc_eh _Unwind_GetRegionStart "" LIBCXXABI_HAS_GCC_EH_LIB)
+check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXXABI_HAS_GCC_S_LIB)
 check_library_exists(c __cxa_thread_atexit_impl ""
----------------
EricWF wrote:
> compnerd wrote:
> > Might be nice to extend this further to allow building against clang_rt.builtins.  We could of course do that as a follow up if you prefer.
> I don't think the clang_rt.builtin libraries are *ever* along the library search path. Maybe we could detect if clang accepts `--rtlib <name>`? (I don't know the flag off hand).
Pretty close with the flag: it is `--rtlib=` if you like the 2 dash version.  Hmm, though the problem with the symbol we are using for gcc_s here is the crus of the issue I think.  The problem is that if clang_rt.builtins is used, `__gcc_personality_v0` will be defined since the symbol is the C personality routine.  Perhaps a compromise may be to change the symbol we use to detect gcc_s.  However, given that this was the original behavior, Im not as concerned, since it has worked for most people so far (and its easy to modify).

================
Comment at: src/CMakeLists.txt:37
@@ +36,3 @@
+
+remove_flags(-Wl,-z,defs)
+
----------------
EricWF wrote:
> compnerd wrote:
> > Do we need to worry about an alternative spelling of `-z defs`?
> Not sure. I only considered the spellings used within the LLVM source tree `llvm/cmake/modules/HandleLLVMOptions.cmake`.
This is a change in the original behavior.  I think it may be safer to add the `-z defs` and `-zdefs` spellings as well if you want the no undefined symbols behavior.  At least on solaris, I believe that `-no-undefined` is also going to cause this to be emitted.

================
Comment at: src/CMakeLists.txt:62
@@ -44,1 +61,3 @@
+# first and last library on the link line. This behavior mimics clang's
+# behavior.
 set(libraries ${LIBCXXABI_CXX_ABI_LIBRARIES})
----------------
Why does gcc_s need to be first?  Is there some symbol that needs to be resolved from it and not another provider?


http://reviews.llvm.org/D15440





More information about the cfe-commits mailing list