[cfe-dev] Using code coverage in clang-cl.exe

[Petr Hosek via cfe-dev]

On Fri, May 11, 2018 at 7:55 AM Reid Kleckner <rnk at google.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).


> ‪On Fri, May 11, 2018 at 4:30 AM ‫ניצן חדד‬‎ <bhmi12 at gmail.com> wrote:‬
>
>> 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
>>
>> 2018-05-11 1:31 GMT+03:00 Reid Kleckner <rnk at google.com>:
>>
>>> 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 at lists.llvm.org> wrote:‬
>>
>>> 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.
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180514/5c1da291/attachment.html>