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

[Richard Smith]

On Fri, Jan 30, 2015 at 11:51 AM, Alexey Samsonov <vonosmas at gmail.com>
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 <richard at metafoo.co.uk>
> wrote:
>
>> 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
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>
>
>
> --
> Alexey Samsonov
> vonosmas at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150130/8f2ea025/attachment.html>