This content has been marked as final. Show 6 replies
I see several possibilities.
The files you are interested in were built without debugging (-g) OR were built with the old style debugging. Try the following and see if your file shows up:
% dumpstabs -s a.out | grep cc
Uncover instrumentation does not rely on the presence of debugging information, though coverage will not be related to source code without -g.
Since you are using the 12.2 compiler, for uncover instrumentation to work on the file you are interested in, it needs to be compiled with optimizations (-xO1 or higher). This restriction is not there in the new 12.3 compiler.
I don't see the source file I am looking for using dumpstabs or dwarfdump. I do see the header file listed, and those methods that have source code in the header file show up in the report. The methods that are just defined in the header file but have their source code in the source file don't show up in the report. The source file is part of a library that is dynamically linked when building the executable. We are using the -g and -xO1 (or higher) flags when building the libraries and executable.
The source file includes member data built from other libraries that can't be instrumented (e.g., Xerces), would that mean the entire source file cannot be instrumented?
For uncover, each binary (executable and shared library) needs to be separately instrumented. So, you need to invoke 'uncover' for each library dependency of the main executable for which you want coverage information.
You could also instrument only the library, and not the main executable if you so desire.
And, as long as a source file is compiled with a supported Studio compiler, it can be instrumented.
It does appear that we need to document this somewhat non-intuitive uncover behavior better.