<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 30, 2014 at 4:20 AM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, May 30, 2014 at 12:41 AM, Alexey Samsonov <<a href="mailto:vonosmas@gmail.com">vonosmas@gmail.com</a>> wrote:<br>

</div><div><div class="h5">> 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>
<br>
</div></div>We don't know how this functionality must work because we don't use it.<br>
It's possible to invent use cases for all 16 permutations of 1/2/3/4.<br>
I think we need to stick with omitting instrumentation of memory<br>
accesses (and intrinsics, at least with best effort), but keep<br>
instrumentation of atomics and func enter/exit. This covers probably<br>
the most common use cases of suppressing known races and improving<br>
performance. Atomics are generally needed to prevent false positives,<br>
so it's risky to remove them. Func enter/exit are needed for good<br>
reports.<br></blockquote><div><br></div><div>I agree. Implemented this in r209940.</div><div><br></div></div><div><br></div>-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>

</div></div>