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.
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
