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

Alexey Samsonov vonosmas at gmail.com
Fri Jan 30 11:51:28 PST 2015


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 <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/c3043419/attachment.html>


More information about the cfe-commits mailing list