On Mon, Jan 19, 2015 at 6:31 PM, Nick Kledzik <[email protected]> wrote: > Kuba, > > I think the logic back when the re-exports were set up was that typeinfo > processing was private to libc++abi.dylib. The public interface was through > __dynamic_cast and __cxa_throw. But now the compiler_rt asan code is walking > the raw type_info data structures and expecting to see these types.
This would never have been correct. These symbols are a documented part of the Itanium C++ ABI (see http://mentorembedded.github.io/cxx-abi/abi.html#namespace), so we're required to make the symbols available. > Linking with libc++abi.dylib works for older OS versions. But, I don’t know > what ASan is doing here, or what the long term solution should be. > > -Nick > > On Jan 17, 2015, at 9:25 PM, Kuba Brecka <[email protected]> wrote: >> I can reproduce on the testcase from >> https://code.google.com/p/address-sanitizer/issues/detail?id=367: >> >> $ ./bin/clang++ a.cpp >> $ ./bin/clang++ a.cpp -fsanitize=undefined >> Undefined symbols for architecture x86_64: >> "typeinfo for __cxxabiv1::__class_type_info", referenced from: >> __ubsan::checkDynamicType(void*, void*, unsigned long) in >> libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o) >> isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, >> __cxxabiv1::__class_type_info const*, long) in >> libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o) >> findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in >> libclang_rt.ubsan_osx.a(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 >> libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o) >> findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in >> libclang_rt.ubsan_osx.a(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 >> libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o) >> findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in >> libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o) >> ld: symbol(s) not found for architecture x86_64 >> clang-3.6: error: linker command failed with exit code 1 (use -v to see >> invocation) >> $ ./bin/clang++ a.cpp -fsanitize=undefined -lc++abi >> $ >> >> The mangled names of these are: >> >> __ZTIN10__cxxabiv117__class_type_infoE >> __ZTIN10__cxxabiv120__si_class_type_infoE >> __ZTIN10__cxxabiv121__vmi_class_type_infoE >> >> It looks like libc++ is actually re-exporting a lot of symbols from >> libc++abi, but it doesn't re-export all of them: >> >> $ dyldinfo -export /usr/lib/libc++.dylib | grep cxxabiv117__class >> [re-export] __ZTSN10__cxxabiv117__class_type_infoE (from libc++abi) >> [re-export] __ZTVN10__cxxabiv117__class_type_infoE (from libc++abi) >> [re-export] __ZTSN10__cxxabiv117__class_type_infoE (from libc++abi) >> [re-export] __ZTVN10__cxxabiv117__class_type_infoE (from libc++abi) >> $ dyldinfo -export /usr/lib/libc++.dylib | grep >> __ZTIN10__cxxabiv117__class_type_infoE >> $ >> >> So it looks like a libc++ issue (assuming the missing symbols are meant to >> be re-exported), and they need to be added to libcxx/lib/libc++abi.exp. >> >> >> http://reviews.llvm.org/D6960 >> >> EMAIL PREFERENCES >> http://reviews.llvm.org/settings/panel/emailpreferences/ >> >> > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
