Nick, Richard, So, if I read this correctly, the correct fix will be to add _ZTIN symbols to lists of libc++abi re-exported from libc++ (libc++abi.exp, libc++abi2.exp, libc++sjlj-abi.exp)?
Even if we add this change, this will only fix problems with trunk libc++/libc++abi, but not with libraries already installed on Mac OS systems. Do you think the suggested patch is a viable workaround? On Tue, Jan 20, 2015 at 3:36 PM, Richard Smith <[email protected]> wrote: > 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 > -- Alexey Samsonov [email protected]
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
