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

[Jean-Daniel Dupas]

In theory, all these symbols should be provided by libc++abi.dylib on OS X. As exported symbols of the libc++abi are reexported by libc++ and libstdc++, linking on one of the standard library should be enough.

Unfortunately, as I said, the current version (OS X 10.8.2) of libc++abi.dylib contains all the required symbols, but they are all declared private, and so are not exported.

nm -m libc++abi.dylib
…
000000000002eb40 (__DATA,__const) non-external (was signed char private external) typeinfo for std::type_info
…
000000000002ebb0 (__DATA,__const) non-external (was signed char private external) typeinfo for __cxxabiv1::__class_type_info

While it is possible to workaround the "typeinfo for std::type_info" issue by forcing the linker to use libstdc++ (which contains this symbol, unlike libc++), it does not fix the problem for the other missing symbols which are only present in libc++abi.


Le 15 nov. 2012 à 15:11, Alexey Samsonov <samsonov at google.com> a écrit :

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

-- Jean-Daniel