Hey Manuel,
I would like to be able to change this behaviour so non-instantiated
code templates are considered as blocks (I think this is the term used
by GCC/GCov). This would help me greatly to uncover unused/untested
codes in a header/template-only library.
First of all: Is this feasible with the GCC infrastructure?
I am not sure about that. It could be harder to get this implemented
since the required information might not be available when you require it.
For this to work, one would probably need access to the internal
representation of the program. It is my understanding that there are
at least two distinct representations of a C++ program: (1) The AST
that only contains the parse tree, before any template instantiation
and (2) the intermediate language representation (GIMPLE?) that will
contain a representation of the instantiated templates. On which level
is coverage instrumentation added right now?
Yes, that's true. You get the details of both representations by using
the additional compiler flags
-fdump-translation-unit (prints out an extended version of GENERIC (= AST))
-fdump-tree-gimple-raw (prints out the second IR known as GIMPLE)
The instrumentation of the source code is finally done on the GIMPLE IR.
You could print out the IR by specifiying -fdump-tree-tree_profile
Second: Where would I start looking?
So far, I have discovered gcov*.{h,c} in the gcc directory. However, I
have not yet found where the .gcno files are written out in the compiler.
There was a recent discussion on the gcc-help mailing list about the
basic internals of GCOV. Please find the thread here:
http://gcc.gnu.org/ml/gcc-help/2011-04/msg00072.html
Third: How hard would it be and how would I proceed?
Naively, my first guess at an approach would be: Locate where the
.gcno file is written out. After writing out all real blocks, identify
all uninitialized template functions, or member functions that are
members of templates, etc. etc. Add a "block" to the .gcno file for
each such function.
As listed above, the .gcno file is written in coverage.c, though you
should look at this one.
I hope that this helps at least a bit to get a step further ...
Best regards,
Andi