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

Alexey Samsonov samsonov at google.com
Thu Nov 15 06:11:17 PST 2012


I wonder why the following line doesn't help then:

+      // The Ubsan runtime library requires C++ and CoreFoundation.
+      AddCXXStdlibLibArgs(Args, CmdArgs);

On Thu, Nov 15, 2012 at 6:05 PM, Alexander Potapenko <glider at google.com>wrote:

> -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
>



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


More information about the cfe-dev mailing list