<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class="">On Aug 23, 2018, at 11:27 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" class="">richard@metafoo.co.uk</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, 23 Aug 2018, 11:13 Vedant Kumar via cfe-dev, <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Aug 23, 2018, at 10:59 AM, David Greene <<a href="mailto:dag@cray.com" target="_blank" rel="noreferrer" class="">dag@cray.com</a>> wrote:<br class="">
> <br class="">
> According to Reid Kleckner over on llvm-dev sanitizers will not work at<br class="">
> all with a statically-linked libc, as the interceptors use dlsym to set<br class="">
> up calls to sigaction and the like. That matched my findings while<br class="">
> debugging the problem we're seeing.<br class="">
<br class="">
Good point, that might be the issue here.<br class=""></blockquote></div></div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">UBSan, unlike the other sanitizers, was explicitly designed to not perform any interception. It's possible that has changed in the interim, of course ...</div></div></div></blockquote><div><br class=""></div>Ah, you're right, I don't think that's changed.</div><div><br class=""></div><div>The standalone version of the UBSan runtime used on Windows does install its own signal handlers. Maybe that causes a bad interaction with Troy's program?</div><div><br class=""></div><div>vedant</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> If sanitizers are supposed to work<br class="">
> with static linking, then it seems like the dependence on dlsym needs to<br class="">
> be broken.<br class="">
> <br class="">
> Otherwise, the sanitizers should catch a nullptr return value from dlsym<br class="">
> and report a friendly user error message. I can write a patch to do<br class="">
> that if it seems like a good idea. Even when linking dynamically, it<br class="">
> would be good to check the return value of dlsym and report the error to<br class="">
> the user.<br class="">
<br class="">
+ 1.<br class="">
<br class="">
vedant<br class="">
<br class="">
<br class="">
> <br class="">
> -David<br class="">
> <br class="">
> Vedant Kumar via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer" class="">cfe-dev@lists.llvm.org</a>> writes:<br class="">
> <br class="">
>> On some platforms it's possible to statically link against the<br class="">
>> ASan/UBSan runtimes using the undocumented -static-libsan option. The<br class="">
>> default behavior on Darwin, Android, and Fuchsia is to link against a<br class="">
>> DSO.<br class="">
>> <br class="">
>> On Aug 23, 2018, at 8:57 AM, Troy Johnson via cfe-dev<br class="">
>> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class="">
>> <br class="">
>> <br class="">
>> <br class="">
>> <br class="">
>> The address sanitizer is documented as not supported with static<br class="">
>> linking, but UBSan does not include the same disclaimer. UBSan<br class="">
>> does not work for me with statically-linked executables. Instead,<br class="">
>> the executables segfault immediately when attempting to install<br class="">
>> signal handlers. Is this expected?<br class="">
>> <br class="">
>> No, that's not expected :). Could you share the options you used to<br class="">
>> compile and link it, and the backtrace you get?<br class="">
>> <br class="">
>> vedant<br class="">
>> <br class="">
>> <br class="">
>> <br class="">
>> -Troy<br class="">
>> <br class="">
>> <br class="">
>> _______________________________________________<br class="">
>> cfe-dev mailing list<br class="">
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer" class="">cfe-dev@lists.llvm.org</a><br class="">
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
>> <br class="">
>> <br class="">
>> _______________________________________________<br class="">
>> cfe-dev mailing list<br class="">
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer" class="">cfe-dev@lists.llvm.org</a><br class="">
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
<br class="">
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div></div></div>
</div></blockquote></div><br class=""></body></html>