Add sync_interception.cc to the WinASan instrumentation blacklist

Add sync_interception.cc to the WinASan instrumentation blacklist

Fixes test failures introduced in https://codereview.chromium.org/1294823003,
due to sandbox interceptors running before ASan initialization.

BUG=521298
TBR=thakis@chromium.org,jschuh@chromium.org,glider@chromium.org

Committed: https://crrev.com/9b4299dbbdb54e69e03719a1e0e46b9d9aa50ffe
Cr-Commit-Position: refs/heads/master@{#353325}

[Reid Kleckner, 2015-10-09 17:30:44]

The CQ bit was checked by rnk@chromium.org

[commit-bot: I haz the power, 2015-10-09 17:33:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1402493002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1402493002/1

[Nico, 2015-10-09 17:34:19]

rs-lgtm

[Nico, 2015-10-09 17:34:22]

rs-lgtm

[Alexander Potapenko, 2015-10-09 17:35:20]

On 2015/10/09 17:33:12, commit-bot: I haz the power wrote:
> CQ is trying da patch. Follow status at
>  https://chromium-cq-status.appspot.com/patch-status/1402493002/1
> View timeline at
>  https://chromium-cq-status.appspot.com/patch-timeline/1402493002/1

Doesn't ASan understand __attribute__((no_sanitize("address"))) on Win?
I think keeping the annotations next to the code is more preferable than having
them in the blacklist file.

[Reid Kleckner, 2015-10-09 17:44:30]

On 2015/10/09 17:35:20, Alexander Potapenko wrote:
> Doesn't ASan understand __attribute__((no_sanitize("address"))) on Win?
> I think keeping the annotations next to the code is more preferable than
having
> them in the blacklist file.

That should work. What about disabling coverage instrumentation? I think we also
have to do that.

[commit-bot: I haz the power, 2015-10-09 17:46:39]

Committed patchset #1 (id:1)

[Reid Kleckner, 2015-10-09 17:47:13]

I also noticed that changing the blacklist file forces a clean build, so the
comments at the tops of these blacklist files appear to be inaccurate. Is clang
writing the blacklist file into the .d files? If so, I think we can change these
comments to talk about how updating them forces a clean build for that sanitizer
class, making it relatively expensive.

[commit-bot: I haz the power, 2015-10-09 17:47:35]

Patchset 1 (id:??) landed as
https://crrev.com/9b4299dbbdb54e69e03719a1e0e46b9d9aa50ffe
Cr-Commit-Position: refs/heads/master@{#353325}

[Nico, 2015-10-09 18:00:51]

On 2015/10/09 17:47:13, Reid Kleckner wrote:
> I also noticed that changing the blacklist file forces a clean build, so the
> comments at the tops of these blacklist files appear to be inaccurate. Is
clang
> writing the blacklist file into the .d files? If so, I think we can change
these
> comments to talk about how updating them forces a clean build for that
sanitizer
> class, making it relatively expensive.

Yes, krasin implemented that in clang r244867 (and r246700). I think we can
probably just remove the comment – any number of changes can force a (nearly)
full build, and full builds happen many times every day.

[Alexander Potapenko, 2015-10-09 18:05:03]

On 2015/10/09 17:47:13, Reid Kleckner wrote:
> I also noticed that changing the blacklist file forces a clean build, so the
> comments at the tops of these blacklist files appear to be inaccurate.
Yes, feel free to fix the comment. I still think it's way better to avoid using
the out-of-line annotations when possible.
> Is clang
> writing the blacklist file into the .d files?
IIUC it does for user-supplied blacklists.
> If so, I think we can change these
> comments to talk about how updating them forces a clean build for that
sanitizer
> class, making it relatively expensive.
Agreed.

[Alexander Potapenko, 2015-10-09 18:06:07]

> That should work. What about disabling coverage instrumentation? I think we
also
> have to do that.

Does this blacklist file affect coverage instrumentation? I really hope it does
not.