[PATCH] Always add -lc++abi when using vptr sanitizer on Darwin.

[Richard Smith]

On Mon, Jan 19, 2015 at 6:31 PM, Nick Kledzik <kledzik at apple.com> 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 <kuba.brecka at gmail.com> 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
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits