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

[Alexey Samsonov]

+glider@

Your Darwin-related patches also look good to me. I don't know much about
Mac world, but I've observed
similar errors on Linux when I tried to add virtual method calls to ASan
runtime. To fix this on Linux
you need to explicitly add "-lstdc++" to linker flags if -fsanitize=address
is present. I don't know
what is the analogue of -lstdc++ on Mac.

On Thu, Nov 15, 2012 at 4:42 PM, Alexey Samsonov <samsonov at google.com>wrote:

> Hi Jean-Daniel!
>
> I've applied parts of your patches relevant to Linux+make build support in
> r168038, r168039.
>
> On Thu, Nov 15, 2012 at 12:34 AM, Jean-Daniel Dupas <
> devlists at shadowlab.org> wrote:
>
>>
>> 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
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
>
> --
> Alexey Samsonov, MSK
>
>


-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121115/c30ae367/attachment.html>