<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 30, 2015 at 11:51 AM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Nick, Richard,</div><div class="gmail_extra"><br></div><div class="gmail_extra">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)?</div><div class="gmail_extra"><br></div><div class="gmail_extra">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?</div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div class="h5"><div class="gmail_quote">On Tue, Jan 20, 2015 at 3:36 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On Mon, Jan 19, 2015 at 6:31 PM, Nick Kledzik <<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>> wrote:<br>
> Kuba,<br>
><br>
> 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.<br>
<br>
</span>This would never have been correct. These symbols are a documented<br>
part of the Itanium C++ ABI (see<br>
<a href="http://mentorembedded.github.io/cxx-abi/abi.html#namespace" target="_blank">http://mentorembedded.github.io/cxx-abi/abi.html#namespace</a>), so we're<br>
required to make the symbols available.<br>
<div><div><br>
>  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.<br>
><br>
> -Nick<br>
><br>
> On Jan 17, 2015, at 9:25 PM, Kuba Brecka <<a href="mailto:kuba.brecka@gmail.com" target="_blank">kuba.brecka@gmail.com</a>> wrote:<br>
>> I can reproduce on the testcase from <a href="https://code.google.com/p/address-sanitizer/issues/detail?id=367" target="_blank">https://code.google.com/p/address-sanitizer/issues/detail?id=367</a>:<br>
>><br>
>>  $ ./bin/clang++ a.cpp<br>
>>  $ ./bin/clang++ a.cpp -fsanitize=undefined<br>
>>  Undefined symbols for architecture x86_64:<br>
>>    "typeinfo for __cxxabiv1::__class_type_info", referenced from:<br>
>>        __ubsan::checkDynamicType(void*, void*, unsigned long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o)<br>
>>        isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o)<br>
>>        findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o)<br>
>>    "typeinfo for __cxxabiv1::__si_class_type_info", referenced from:<br>
>>        isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o)<br>
>>        findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o)<br>
>>    "typeinfo for __cxxabiv1::__vmi_class_type_info", referenced from:<br>
>>        isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o)<br>
>>        findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o)<br>
>>  ld: symbol(s) not found for architecture x86_64<br>
>>  clang-3.6: error: linker command failed with exit code 1 (use -v to see invocation)<br>
>>  $ ./bin/clang++ a.cpp -fsanitize=undefined -lc++abi<br>
>>  $<br>
>><br>
>> The mangled names of these are:<br>
>><br>
>>  __ZTIN10__cxxabiv117__class_type_infoE<br>
>>  __ZTIN10__cxxabiv120__si_class_type_infoE<br>
>>  __ZTIN10__cxxabiv121__vmi_class_type_infoE<br>
>><br>
>> It looks like libc++ is actually re-exporting a lot of symbols from libc++abi, but it doesn't re-export all of them:<br>
>><br>
>>  $ dyldinfo -export /usr/lib/libc++.dylib | grep cxxabiv117__class<br>
>>  [re-export] __ZTSN10__cxxabiv117__class_type_infoE (from libc++abi)<br>
>>  [re-export] __ZTVN10__cxxabiv117__class_type_infoE (from libc++abi)<br>
>>  [re-export] __ZTSN10__cxxabiv117__class_type_infoE (from libc++abi)<br>
>>  [re-export] __ZTVN10__cxxabiv117__class_type_infoE (from libc++abi)<br>
>>  $ dyldinfo -export /usr/lib/libc++.dylib | grep __ZTIN10__cxxabiv117__class_type_infoE<br>
>>  $<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> <a href="http://reviews.llvm.org/D6960" target="_blank">http://reviews.llvm.org/D6960</a><br>
>><br>
>> EMAIL PREFERENCES<br>
>>  <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
>><br>
>><br>
><br>
><br>
</div></div><div><div>> _______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div></div>
</font></span></div></div>
</blockquote></div><br></div></div>