<div dir="ltr">Now that the blacklist implementation has been moved to the frontend, will there be any change in behavior w.r.t. name mangling? Previously only the mangled names were matched against the blacklist. I think it makes more sense to use the demangled names, or both.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 31, 2014 at 4:23 AM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, May 30, 2014 at 1:53 AM, Evgeniy Stepanov <span dir="ltr"><<a href="mailto:eugeni.stepanov@gmail.com" target="_blank">eugeni.stepanov@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Fri, May 30, 2014 at 12:41 AM, Alexey Samsonov <<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> I consider reducing the usage of blacklist in sanitizer instrumentation<br>
> passes and doing the necessary work in frontend (Clang) instead.<br>
><br>
> Some of it is already implemented: e.g. Clang will attach an attribute<br>
> "sanitize_address" to function definition only if this function is not<br>
> blacklisted. In this case we won't instrument the memory accesses in this<br>
> function in ASan instrumentation pass, so there's no need to looking at<br>
> blacklist once again.<br>
><br>
> TSan pass does the following:<br>
><br>
> 1) instruments plain memory accesses<br>
> 2) instruments atomic accesses<br>
> 3) instruments memory intrinsics calls.<br>
> 4) adds function entry/exit callbacks.<br>
><br>
> If a function doesn't have sanitize_thread attribute (e.g. it was annotated<br>
> with __attribute__((no_sanitize_thread)) ), then it still does (2), (3) and<br>
> (4). If a function is blacklisted,<br>
> TSan pass does nothing. Shouldn't the behavior be the same? I think, we must<br>
> always do (4) to get<br>
> good stack traces, and probably do (2) (we may report races on atomics in<br>
> this case, but otherwise<br>
> we may miss synchronization). Thoughts?<br>
<br>
</div></div>I don't think we should do (2).<br>
<br>
Sounds like your plan would let us drop blacklist from *SanitizerPass<br>
arguments, right? That's great.<br></blockquote><div><br></div></div></div><div>Yes. We can already do that for TSan and MSan - sanitize_memory and sanitize_thread</div><div>attrs are not added to functions by Clang if the functions are blacklisted. There's still some</div>
<div>stuff to do in ASan w.r.t. global variables.</div><div><br></div><div>BTW, are we still interested in having "-mllvm -msan-blacklist" and "-mllvm -tsan-blacklist",</div><div>or we may kill these flags as well, and rely only on a frontend Clang compiler flag?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br>
<br>
><br>
> --<br>
> Alexey Samsonov<br>
> <a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a><span class="HOEnZb"><font color="#888888"><br>
</font></span></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>
</font></span></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>