[cfe-dev] -fsanitize=undefined and shared libraries

[Richard Smith]

On Fri, Jan 11, 2013 at 4:30 PM, Will Dietz <willdtz at gmail.com> wrote:

> On Fri, Jan 11, 2013 at 11:40 AM, zapadinsky <zapadinsky at gmail.com> wrote:
> > I have had a similar problem with integer checks. compiler-rt was not
> linked
> > to .so files and there were unknown references to
> > __ubsan_handle_add_overflow and so on.
> >
>
> Do you have a means for reproducing this failure on trunk?  A short
> example would be helpful :).
>
> If you don't have one handy, I can probably put one together sometime
> next week.  I'm pretty sure I've seen this a few times, even after the
> visibility fix.
>
> > I managed this issue adding "-Wl,--whole-archive
> > -L/usr/local/lib/clang/3.3/lib/linux/ -lclang_rt.ubsan-i386
> > -Wl,--no-whole-archive" to command line... and its not a beautiful
> solution.
> >
>
> This is what clang does for asan, and I suspect we could do something
> similar for ubsan.  To avoid requiring a C++ runtime, perhaps we could
> build two ubsan libraries (ubsan, ubsan-cxx) and link them in as
> appropriate.  The ubsan code already builds the C++ handlers in
> separate TU's, so hopefully this wouldn't take much work.
>

Using --whole-archive here would break "-fsanitize=address,undefined",
since you'd link in sanitizer_common twice. This change would be
unnecessary if we were to always link to the ubsan runtime, as you suggest
below.


> In a different direction, I notice that we don't link in the ubsan
> runtime when building a shared library.  Why is this? (to avoid code
> duplication, issues with -fPIC, some static initializer/internal state
> concern?)  Removing this check on my local clang copy has resolved
> this issue for me, and is presently how I'm building programs.
> However, I'm reluctant to propose this as a solution without knowing
> why things are the way they are first :).


The current approach matches the approach taken for the other sanitizers.
In general, the main binary must be linked with all the -fsanitize= flags
used to build the constituent parts, right now. This restriction makes some
sense for ASan, TSan, and MSan (since they need to do invasive things to
the program as a whole), but we can probably remove it for UBSan.


> > When this issue will be fixed in trunk?
>
> As soon as someone reports it (looks like you've kicked that off,
> thanks!) and we understand the issue well enough to fix it (perhaps
> others on the list already know a good solution).
>
> Thanks for bringing this up, and here's hoping it's resolved soon.
>
> ~Will
>
> >
> >
> >
> > --
> > View this message in context:
> http://clang-developers.42468.n3.nabble.com/fsanitize-undefined-and-shared-libraries-tp4029561p4029653.html
> > Sent from the Clang Developers mailing list archive at Nabble.com.
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130111/54f5aecd/attachment.html>