Using code coverage in clang-cl.exe

Hi awesome community,

I am trying to use this feature:
https://clang.llvm.org/docs/SourceBasedCodeCoverage.html

with clang-cl.exe.

I can see in https://clang.llvm.org/docs/UsersManual.html#id8
that -fprofile-instr-generate exists in clang-cl interface but -fcoverage-mapping doesn’t exist, even though it does exist in clang++.

Can anyone shed some light on why this feature doesn’t exist in clang-cl? it there a plan to future insert it?

Thanks,

Nitzan.

I made these available in clang-cl in r332053. I have no idea if it works on Windows at all, though. In the meantime, you can probably enable this functionality by escaping the flag with -Xclang -fcoverage-mapping.

There isn’t any particular reason why flags aren’t available in clang-cl. We effectively whitelist gcc-style flags one at a time for inclusion in the clang-cl command line interface. At some point I would like to do something like whitelist all -f flags, since they are unlikely to conflict with future MSVC flags.

‪On Wed, May 9, 2018 at 5:49 PM ‫ניצן חדד via cfe-dev‬‎ <cfe-dev@lists.llvm.org> wrote:‬

Hi,

I made these available in clang-cl in r332053. I have no idea if it works
on Windows at all, though. In the meantime, you can probably enable this
functionality by escaping the flag with -Xclang -fcoverage-mapping.

There isn't any particular reason why flags aren't available in clang-cl.
We effectively whitelist gcc-style flags one at a time for inclusion in the
clang-cl command line interface. At some point I would like to do something
like whitelist all -f flags, since they are unlikely to conflict with
future MSVC flags.

Somewhat related: the other day I wanted to have a compilation database
for a project still using nmake (libxmlsec). The code nicely compiles
with clang-cl, but I could not use the (otherwise available) -MJ flag to
build a compilation database as it's not reachable via clang-cl.

I'm not sure if there is already a naming convention how to expose
"-M..." with clang-cl, though. :slight_smile:

Would it make sense to expose it in some way? Should I file a bug for
this? (I don't have a clang dev setup on Windows, so it's not easy for
me to look at this myself.)

Thanks a lot,

Miklos

Hi Reid,

I just tried compiling chrome-win with -fprofile-instr-generate -Xclang -fcoverage-mapping ( I edited the build.gn file in the win toolchain) , and I get link errors.
I don’t see any reason why the feature wouldn’t work on windows,I am using clang version 7.0.0 (trunk 330570).

These are the errors I received:
LINK(DLL) common.dll common.dll.lib common.dll.pdb
FAILED: common.dll common.dll.lib common.dll.pdb
C:/src/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe …/…/build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /IMPLIB:./common.dll.lib /DLL /OUT:./common.dll /PDB:./common.dll.pdb @./common.dll.rsp
gcm_messages.obj : error LNK2019: unresolved external symbol __llvm_profile_runtime referenced in function __llvm_profile_runtime_user
gcm_messages.obj : error LNK2019: unresolved external symbol __llvm_profile_register_function referenced in function __llvm_profile_register_functions
gcm_messages.obj : error LNK2019: unresolved external symbol __llvm_profile_register_names_function referenced in function __llvm_profile_register_functions
./common.dll : fatal error LNK1120: 3 unresolved externals
[693/29165] CXX obj/device/bluetooth/public/mojom/mojom_blink/uuid.mojom-blink.obj

ninja: build stopped: subcommand failed.

Do you have any idea why the chrome build will fail with these flags?

Thanks,

Nitzan

Adding this cflag will not add the clang_rt.profile-*.lib library to the link line. You would have to figure out the proper name for it (similar to how we handle ASan) and add it to the build.

In the future, I hope we can simplify compiler-rt’s library naming so that all you have to do is add -lclangrt_profile or /defaultlib:clangrt_profile or something like that and it will just work, instead of having the architecture in the library name.

‪On Fri, May 11, 2018 at 4:30 AM ‫ניצן חדד‬‎ <bhmi12@gmail.com> wrote:‬

Adding this cflag will not add the clang_rt.profile-*.lib library to the link line. You would have to figure out the proper name for it (similar to how we handle ASan) and add it to the build.

In the future, I hope we can simplify compiler-rt’s library naming so that all you have to do is add -lclangrt_profile or /defaultlib:clangrt_profile or something like that and it will just work, instead of having the architecture in the library name.

This will be enabled by https://reviews.llvm.org/D45604 (except it uses . as a separator rather than _ so it’ll be -lclang_rt.profile).