Controlling generation of coverage symbols

Clang Frontend Using Clang
1

Hi,

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?

Kind regards.

Artur

2

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

Nick

3

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.

4

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.

5

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.