This is an archive of the discontinued LLVM Phabricator instance.

[UBSan] Use shared library for UBSan on OS X (compiler-rt part).
ClosedPublic

Authored by samsonov on Mar 19 2015, 4:21 PM.

Diff Detail

Event Timeline

samsonov updated this revision to Diff 22321.Mar 19 2015, 4:21 PM
samsonov retitled this revision from to [UBSan] Use shared library for UBSan on OS X (compiler-rt part)..
samsonov updated this object.
samsonov edited the test plan for this revision. (Show Details)
samsonov added reviewers: zaks.anna, kubamracek.
samsonov added a subscriber: Unknown Object (MLST).
kubamracek edited edge metadata.Mar 22 2015, 9:29 AM

This doesn't build on my OS X 10.10 system, with the following link error (building with CMake+Ninja):

Linking CXX shared library lib/clang/3.7.0/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib
FAILED: ... /usr/bin/c++ -o lib/clang/3.7.0/lib/darwin/libclang_rt.ubsan_osx_dynamic.dylib ...
Undefined symbols for architecture x86_64:
  "typeinfo for __cxxabiv1::__class_type_info", referenced from:
      __ubsan::checkDynamicType(void*, void*, unsigned long) in ubsan_type_hash.cc.o
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in ubsan_type_hash.cc.o
      findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in ubsan_type_hash.cc.o
  "typeinfo for __cxxabiv1::__si_class_type_info", referenced from:
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in ubsan_type_hash.cc.o
      findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in ubsan_type_hash.cc.o
  "typeinfo for __cxxabiv1::__vmi_class_type_info", referenced from:
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in ubsan_type_hash.cc.o
      findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in ubsan_type_hash.cc.o
ld: symbol(s) not found for architecture x86_64

This looks like the same issue that was discussed at http://reviews.llvm.org/D6960, and the proposed solution (explicitly linking against libc++abi.dylib) should fix this. I'm not sure if that's the right thing to do here, it was suggested that we shouldn't link against libc++abi, and the issue should be fixed in libc++ re-export list. However, this would only be available in the next OS X version. So unless someone has a strong reason why not, we might need to really explicitly link against libc++abi.

I think we should just link against libc++abi to make it work in the current Mac OS version. Can you check if linking ubsan dylib with -lc++abi would fix the issue?

I think we should just link against libc++abi to make it work in the current Mac OS version. Can you check if linking ubsan dylib with -lc++abi would fix the issue?

Yes, it does fix the issue.

OK, I will make this changes and try to submit the patch on Monday.

zaks.anna edited edge metadata.Mar 23 2015, 2:48 PM

I was able to build the makefile build with these changes.

make/platform/clang_darwin.mk
242

I think we should pass -lc++ on all platforms to make sure we link against libc++.

samsonov added inline comments.Mar 23 2015, 4:12 PM
make/platform/clang_darwin.mk
242

Why do we then explicitly pass -stdlib=libc++ compile flags only on OS X, but not on iOS simulator? Could you somehow check if passing -stdlib=libc++ / -lc++ everywhere works?

This revision was automatically updated to reflect the committed changes.

Thanks for testing this!

I've submitted this change in r233036. Let's see if it would work and not break the bots. Switching to libc++ everywhere (including in ASan) is a different thing, and we can proceed with it once we know how to test/verify it.