[cfe-users] Controlling generation of coverage symbols

Artur Szostak aszostak at partner.eso.org
Mon Oct 27 06:38:13 PDT 2014


>>>>>> Is there any way to control how the symbols related to code coverage such as
>>>>>> _llvm_gcov_init are created?
>>>>>> Specifically can they be disabled? or forced? or made to be public/exported?

>>>>> Disabling code coverage will disable creation of these symbols. Beyond that,
>>>>> we don't offer fine grained control over them. Why do you ask?

>>>> Thanks you for the information.
>>>>
>>>> Just one additional question, am I correct to understand that the code for
>>>> _llvm_gcov_init is implicitly injected into the binary? The reason I ask is there
>>>> are some posts floating around online talking about linking against libprofile_rt.a.
>>>> But I suspect this is not relevant.

>>> We do not inject the functions into the binary, only calls to them. The
>>> definitions are in libprofile_rt.a as you suspect, which is part of the compiler-rt
>>> project. Clang adds that to the link if you pass the coverage flags when linking.

>> Hmm... I'm confused now, where on earth is the library then on OS X?

> They may have renamed it to libclang_rt?
> 
> You can run "clang -### ..." to find what subcommands clang will run with full paths,
> and see what additional library it adds when linking with --coverage vs. without.
 
OK, the -### was very helpful. Indeed on OS X Mavericks the standard command line
compiler tools installation is using libclang_rt.osx.a.
Thank you for pointing that out.
This clears up my confusion and solves my problem.



More information about the cfe-users mailing list