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

[Alexey Samsonov]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121115/5b3857c6/attachment.html>