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

Jean-Daniel Dupas devlists at shadowlab.org
Fri Nov 23 09:11:45 PST 2012


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

> 
> 
> On Fri, Nov 23, 2012 at 4:14 AM, Sean McBride <sean at rogue-research.com> wrote:
> On Tue, 20 Nov 2012 19:08:48 -0800, Richard Smith said:
> 
> >Sorry, I don't know which Xcode versions correspond to which Clang
> >revisions.
> 
> Don't think anyone outside Apple does. :(
> 
> >Clang has supported __int128 since r153999, which landed on
> >3rd April, and was included in the Clang 3.1 release.
> 
> The current Xcode (4.5.2) says:
> 
> Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
> 
> I fear it may discourage OS X users from playing with open source clang, when the only compiler they have to bootstrap it is the clang binary from Xcode, which apparently is too old. :(
> 
> >> Anyway, now -fcatch-undefined-behavior works, yay!  Umm, I mean -
> >fsanitize=undefined. :)
> >
> >I'm happy to hear it.
> 
> I spoke a bit soon... it certainly works way better than before, but I still get link errors building if I use the 'vptr' sanitizer with C++ code.  ex:
> 
> Yes, I see the same problems with vptr sanitizer on Mac.
> Richard, do you have an idea of how we can fix ubsan_type_hash.cc on Darwin, or should we
> just disable vptr sanitizer (and exclude it from -fsanitize=undefined expansion) on darwin targets for now?
>  

As I said previously, this issue is due to missing symbols in darwin's C++ libs. I don't think there is an easy way to fix this. Apple should update libc++abi and libc++ to fix this issue (the LLVM libc++abi library already does it, and a fix is already present in libc++ but is explicitly disabled: lib/libc++abi2.exp).

IMHO, the best option right now is to disable this sanitizer in the driver when targeting darwin (maybe emitting a warning if it is explicitly required using 'vptr' an not implicitly defined using 'undefined').

> 
> Undefined symbols for architecture x86_64:
>   "__ZTIN10__cxxabiv117__class_type_infoE", referenced from:
>       __ZN7__ubsan16checkDynamicTypeEPvS0_m in libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o)
>       __ZL21isDerivedFromAtOffsetPKN10__cxxabiv117__class_type_infoES2_l in libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o)
>   "__ZTIN10__cxxabiv120__si_class_type_infoE", referenced from:
>       __ZL21isDerivedFromAtOffsetPKN10__cxxabiv117__class_type_infoES2_l in libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o)
>   "__ZTIN10__cxxabiv121__vmi_class_type_infoE", referenced from:
>       __ZL21isDerivedFromAtOffsetPKN10__cxxabiv117__class_type_infoES2_l in libclang_rt.ubsan_osx.a(ubsan_type_hash.cc.o)
> 
> Cheers,
> 
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
> 
> 
> 
> 
> 
> -- 
> Alexey Samsonov, MSK
> 

-- Jean-Daniel




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121123/064bda11/attachment.html>


More information about the cfe-dev mailing list