First thing is that fno-cxa-atexit doesn't work with clang-cl. Why do we have this flag? I don't think it's needed on Windows. __cxa_atexit is an Itanium C++ ABI thing. We use regular atexit on Windows anyway.

I'll send a patch to remove it from the BUILD.gn for now.

Once I do that, things crash:
[1333/1543] CC obj/third_party/libxml/libxml/parser.obj
FAILED: obj/third_party/libxml/libxml/parser.obj
...
fatal error: error in backend: File exit not handled before popRegions
clang-cl.exe: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 7.0.0 (trunk 332838)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\src\chromium\src\third_party\llvm-build\Release+Asserts\bin
clang-cl.exe: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang-cl.exe: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-cl.exe: note: diagnostic msg: C:\Users\rnk\AppData\Local\Temp\goma\goma_temp.2492\parser-680f93.sh
clang-cl.exe: note: diagnostic msg:

********************

I'll dig into that next.

Reduction:

#define a b
char c() {
  if (0)
    goto a;
a:
  return 0;
}

Compiling that with clang -c t.c -fprofile-instr-generate -fcoverage-mapping crashes. =/

Looks like someone else has hit this: https://bugs.llvm.org/show_bug.cgi?id=35867

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

commit 9aa0375e58d62b3134cc38363e0b54b8bf2208af
Author: Reid Kleckner <rnk@google.com>
Date: Fri Jun 01 00:38:54 2018

Don't pass -fno-cxa-atexit to clang-cl when enabling code coverage

On Windows, clang always uses regular atexit, so this wouldn't do
anything even if clang-cl did understand the flag.

R=mmoroz@chromium.org
BUG=846918

Change-Id: I59523e818488b5de3331a7851ae51a381a3e5c17
Reviewed-on: https://chromium-review.googlesource.com/1081202
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Commit-Queue: Reid Kleckner <rnk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#563460}
[modify] https://crrev.com/9aa0375e58d62b3134cc38363e0b54b8bf2208af/build/config/coverage/BUILD.gn

Reid, I guess we need a clang roll now, since the upstream bug mentioned in c#4 is fixed now?

The roll happening in  issue 845798  should be sufficient, it rolls up to r334100, while we need r333715.

Ping. Reid, could you please take another look when you get a chance?

I poked at it and came up with a CL to fix the ldflags:
https://chromium-review.googlesource.com/1153625

I think after that, we might be running into this:
https://bugs.llvm.org/show_bug.cgi?id=38340

What I see is an attempt to fwrite() on a null or invalid file handle during profile writing.

Mozilla is trying PGO, which uses similar infrastructure.

So, that's fixed in r338172. We need to wait for https://chromium-review.googlesource.com/1153625 to land and then roll clang and then we can try coverage on some more complicated test binaries. I got sql_unittests running with coverage locally.

That sounds fantastic! Thanks for the update, Reid!

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

commit 0cbb2ddc9cec38649e71ba2c3bfb0ba3b240e76c
Author: Reid Kleckner <rnk@google.com>
Date: Mon Jul 30 20:49:07 2018

Fix linking against the clang profiling library on Windows

On Windows, the linker is invoked directly, so we can't add
-finstr-profile-generate to ldflags and expect things to work. Instead,
explicitly link against the appropriate library.

Update clang's package.py script to include clang_rt.profile-*.lib.

After this, base_unittests links, but crashes during shutdown when
writing the profile.

BUG=846918
R=thakis@chromium.org,mmoroz@chromium.org

Change-Id: I337e587b83750c86546a9673daeb593d4125bbd9
Reviewed-on: https://chromium-review.googlesource.com/1153625
Commit-Queue: Reid Kleckner <rnk@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579161}
[modify] https://crrev.com/0cbb2ddc9cec38649e71ba2c3bfb0ba3b240e76c/build/config/coverage/BUILD.gn
[modify] https://crrev.com/0cbb2ddc9cec38649e71ba2c3bfb0ba3b240e76c/tools/clang/scripts/package.py

Let's do another roll.

This needs some testing, but even if it works, we have one more thing we should do: non-dynamic counter registration, i.e. make needsRuntimeRegistrationOfSectionRange() return false for COFF targets in InstrProfiling.cpp.

Otherwise coverage and PGO binaries will have extra startup overhead. It's been done for Linux and Mac, but not for COFF targets. It requires doing that .lprf[cnd]$A/X/Z section sorting and registration thing.

As far as testing goes: I compiled all of Chromium with instrumentation, ran the browser and unittests, collected some profile information, and used it to build an optimized version. No issues observed.

inglorion@, that sounds awesome! Looks like it's time for me to set up my new Windows desktop :)

@rnk, @inglorion: It sounds that blockers to enable code coverage on Windows were all fixed. Is there a doc on how to run this end to end?

I think you mostly add use_clang_coverage=true and run the binary and it'll write out coverage files.

An open source user is still reporting it doesn't work for them in opencv:
https://bugs.llvm.org/show_bug.cgi?id=37561

We might want to run that down before declaring victory.

Followup to c#15. Completed a PGO build with ThinLTO optimizations enabled, but had to set "v8_use_snapshot = false" due to errors during compiling.

The V8 error appears to be ThinLTO related to V8 embedded builtins assembly generation. Hopefully should be resolved when this rolls into Chromium:

https://chromium.googlesource.com/v8/v8/+/bd8ed720cfa0533e4732490f5240380e234e469e