<div dir="ltr"><div>Great, that works! The next linking error I get is:<br><br> 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<br>
<br></div>It's a little trouble for me to narrow down the test case, but I'm happy to do it if it helps.<br><br>Thanks,<br>Martin<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 11, 2013 at 9:44 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Jan 11, 2013 at 4:30 PM, Will Dietz <span dir="ltr"><<a href="mailto:willdtz@gmail.com" target="_blank">willdtz@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Fri, Jan 11, 2013 at 11:40 AM, zapadinsky <<a href="mailto:zapadinsky@gmail.com" target="_blank">zapadinsky@gmail.com</a>> wrote:<br>
> I have had a similar problem with integer checks. compiler-rt was not linked<br>
> to .so files and there were unknown references to<br>
> __ubsan_handle_add_overflow and so on.<br>
><br>
<br>
</div>Do you have a means for reproducing this failure on trunk? A short<br>
example would be helpful :).<br>
<br>
If you don't have one handy, I can probably put one together sometime<br>
next week. I'm pretty sure I've seen this a few times, even after the<br>
visibility fix.<br>
<div><br>
> I managed this issue adding "-Wl,--whole-archive<br>
> -L/usr/local/lib/clang/3.3/lib/linux/ -lclang_rt.ubsan-i386<br>
> -Wl,--no-whole-archive" to command line... and its not a beautiful solution.<br>
><br>
<br>
</div>This is what clang does for asan, and I suspect we could do something<br>
similar for ubsan. To avoid requiring a C++ runtime, perhaps we could<br>
build two ubsan libraries (ubsan, ubsan-cxx) and link them in as<br>
appropriate. The ubsan code already builds the C++ handlers in<br>
separate TU's, so hopefully this wouldn't take much work.<br></blockquote><div><br></div></div><div>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.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In a different direction, I notice that we don't link in the ubsan<br>
runtime when building a shared library. Why is this? (to avoid code<br>
duplication, issues with -fPIC, some static initializer/internal state<br>
concern?) Removing this check on my local clang copy has resolved<br>
this issue for me, and is presently how I'm building programs.<br>
However, I'm reluctant to propose this as a solution without knowing<br>
why things are the way they are first :).</blockquote><div><br></div></div><div>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.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> When this issue will be fixed in trunk?<br>
<br>
</div>As soon as someone reports it (looks like you've kicked that off,<br>
thanks!) and we understand the issue well enough to fix it (perhaps<br>
others on the list already know a good solution).<br>
<br>
Thanks for bringing this up, and here's hoping it's resolved soon.<br>
<span><font color="#888888"><br>
~Will<br>
</font></span><div><div><br>
><br>
><br>
><br>
> --<br>
> View this message in context: <a href="http://clang-developers.42468.n3.nabble.com/fsanitize-undefined-and-shared-libraries-tp4029561p4029653.html" target="_blank">http://clang-developers.42468.n3.nabble.com/fsanitize-undefined-and-shared-libraries-tp4029561p4029653.html</a><br>
> Sent from the Clang Developers mailing list archive at Nabble.com.<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div></div><br>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>