[cfe-dev] recent change broke -fcatch-undefined-behavior

[Jean-Daniel Dupas]

Le 14 nov. 2012 à 21:11, Richard Smith <richard at metafoo.co.uk> a écrit :

> On Wed, Nov 14, 2012 at 7:40 AM, Sean McBride <sean at rogue-research.com> wrote:
>> On Tue, 13 Nov 2012 16:17:39 -0800, Richard Smith said:
>> 
>>> Thanks for the prod, I've checked in some pending patches to add OS X
>>> support, in r167888, r167889, and r167890. If you could build
>>> clang_rt.ubsan_osx and let me know whether everything is working as
>>> intended, that'd be great; we can then ask to get those patches pulled
>>> onto the 3.2 branch.
>> 
>> I've rebuilt clang r167897 and still get link errors, ex:
>> 
>> Undefined symbols for architecture x86_64:
>>  "___ubsan_handle_shift_out_of_bounds", referenced from:
> 
> I don't have a Darwin machine to test against. Does the attached patch help?
> <driver-ubsan-darwin.diff>


This patch is definitively a step in the right direction. 

We need to tweak to clang runtime makefile to tell it to build ubsan on OS X (ubsan-make.patch).

Also, in the previous compiler-rt patch has an issue. It neither builds sanitize-common objects, not include them in the ubsan archive.
I fix this by looking at how asan is actually built (ubsan.patch). Note that this patch make the previous change to the compiler-rt SDK headers useless, as building sanitizer-common requires a full SDK, and so we now use the system headers instead of the headers provided by compiler-rt.

But I hit a blocking issue that I don't know how to workaround.
AFAIK, on darwin, there is no library that currently provide "typeinfo for std::type_info".
The libc++abi provided by OS X does not properly export this symbol (and other typeinfo related symbols). As ubsan_type_hash.cpp require them, trying to link a software with the libubsan produce the following error:

  "typeinfo for __cxxabiv1::__class_type_info", referenced from:
      __ubsan::checkDynamicType(void*, void*, unsigned long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
  "typeinfo for std::type_info", referenced from:
      vtable for testing::internal::ExecDeathTest in gtest-all.o
      __ubsan::checkDynamicType(void*, void*, unsigned long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.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.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.o)


Does someone with more knowledge about this subject can help ?


-- Jean-Daniel



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121114/1277152b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ubsan-make.patch
Type: application/octet-stream
Size: 1558 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121114/1277152b/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121114/1277152b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ubsan.patch
Type: application/octet-stream
Size: 839 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121114/1277152b/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121114/1277152b/attachment-0002.html>