On Fri, Jan 30, 2015 at 11:51 AM, Alexey Samsonov <[email protected]> wrote:
> 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? > If it's appropriate to assume that every Darwin C++ compilation will use libc++abi, it seems plausible as a workaround, but I don't know that's a valid assumption. 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
