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

[Alexander Potapenko]

-lstdc++ should also work on Mac.

On Thu, Nov 15, 2012 at 4:52 PM, Alexey Samsonov <samsonov at google.com> wrote:
> +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
>



-- 
Alexander Potapenko
Software Engineer
Google Moscow