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

[Martin Martin]

Great, that works!  The next linking error I get is:

 hidden symbol `__ubsan_vptr_type_cache' in
/home/martin/clang/build/bin/../lib/clang/3.3/lib/linux/libclang_rt.ubsan-x86_64.a(ubsan_type_hash.cc.o)
is referenced by DSO

It's a little trouble for me to narrow down the test case, but I'm happy to
do it if it helps.

Thanks,
Martin


On Fri, Jan 11, 2013 at 9:44 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> 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
>>
>
>
> _______________________________________________
> 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/20130112/eb1a5494/attachment.html>