Actually, from reading the output of 'link.exe -verbose', this seems like a more general clang issue. Something is preventing the linker from doing its normal deletion of unused code, and that's why chrome_elf depends on user32.dll.

FYI: https://bugs.chromium.org/p/chromium/issues/detail?id=647315

Pri-2, as I'm quite sure WinASan is being pushed out to users?  chrome_elf doesn't work as expected when user32.dll gets pulled in by a sneaky new dependency and is loaded at process startup.

rnk@, where do we currently ship winasan, and is this test still failing for you?  Could you throw your chrome_elf binary into Depends or IDA and see who is pulling in user32.dll?  I assume some dependency that is WinASan specific?

We ship syzyasan to users today, not llvm asan, so I think P3 is OK.

My chrome_elf.dll depends directly on user32.dll:
$ dumpbin -dependents chrome_elf.dll | grep USER
    USER32.dll

This is not asan specific, this was using these gn args:
"""
is_clang = true
is_component_build = false
is_debug = false
symbol_level = 1
target_cpu = "x86"
enable_nacl = false
"""

I think this might be some local build issue for me, though, and not related to the test failure we see on the bots, because I downloaded an archived Clang build, and it chrome_elf.dll there did not depend on USER32.dll. My local chrome_elf build imported MessageBoxW from user32 because it gets called from somewhere in base, and that code wasn't being dead stripped for reasons I don't yet understand.

So, ignoring all my local attempts to debug this because I'm probably holding something wrong, my best guess is that asan depends on dbghelp.dll, and delay loading it somewhere new might fix the problem.

Delay loading dbghelp.dll might fix some of this:
https://reviews.llvm.org/D26473

Doesn't seem like it helped. Maybe it's because we don't enable /Gw with ASan?

https://cs.chromium.org/chromium/src/build/config/compiler/BUILD.gn?rcl=0&l=1226
https://codereview.chromium.org/832583007

This logic was added to the gyp build in https://codereview.chromium.org/811083003 to solve https://bugs.chromium.org/p/chromium/issues/detail?id=445383

I've convinced myself that the chrome ELF import test relies on linker dead stripping (/OPT:REF). ASan's global registration system defeats linker dead stripping, because it adds an array to every object file that references all globals defined in that object file. This prevents dropping any dead globals, which prevents dropping some usages of user32.dll from chrome //base. So, removing /Gw from the build is probably necessary, but doesn't completely solve the problem.

I think for now we should disable this test, but I assume that if we ever want to ship LLVM instrumented asan builds to users, we will need to eliminate the user32 import.

The problem was simpler than I thought it was. It wasn't that ASan defeated /OPT:REF, it was that /OPT:REF wasn't enabled at all to begin with. I incorrectly thought that /OPT:ICF implied /OPT:REF, since ICF seems like a more powerful optimization than garbage collection.

Chromium's build doesn't enable /OPT:REF in non-official clang builds, so we should just fix that and call it a day:
https://cs.chromium.org/chromium/src/build/config/win/BUILD.gn?q=OPT:REF&sq=package:chromium&l=106&dr=C

In official builds, we tack on an additional /OPT:REF flag here, which makes all the non-ASan Windows Clang ToT bots pass this test:
https://cs.chromium.org/chromium/src/build/config/compiler/BUILD.gn?q=OPT:REF&sq=package:chromium&l=1247&dr=C

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7bff5aca5d8144576a46b3dc0a37086c7e1a8d25

commit 7bff5aca5d8144576a46b3dc0a37086c7e1a8d25
Author: rnk <rnk@chromium.org>
Date: Tue Nov 22 18:55:19 2016

Use /OPT:REF in clang static release builds

Chromium normally builds with /PROFILE in static release builds, which
implies "/OPT:REF /OPT:ICF /INCREMENTAL:NO /FIXED:NO". We can't use
/PROFILE with Clang, so instead pass the list of implied flags to make
Clang builds more closely match MSVC builds. We already do this for
is_win_fastlink=true builds, presumably for the same reason.

It turns out that the chrome_elf_unittests relies on /OPT:REF because it
allows the linker to remove unused user32.dll dependencies brought in by
//base. These tests only run in release+static builds, and most clang
release+static bots do official builds. Official builds already use
/OPT:REF for unrelated reasons, so we only see these test failures on
ASan bots, which don't do official builds.

BUG= 646414 
R=thakis@chromium.org

Review-Url: https://codereview.chromium.org/2520373003
Cr-Commit-Position: refs/heads/master@{#433929}

[modify] https://crrev.com/7bff5aca5d8144576a46b3dc0a37086c7e1a8d25/build/config/win/BUILD.gn

Bot went green with the /OPT:REF CL:
https://build.chromium.org/p/chromium.fyi/builders/CrWinAsan%20tester/builds/1425