Unlike other tools such as gdb that need source files, gcov does not store the
absolute path. As a result, gcov must be run in the same directory in which gcc
was invoked. This makes it particularly difficult to generate coverage reports
for separately compiled libraries that have separate src/ and build/
directories.
Below is a shell script that demonstrates the problem.
#!/bin/sh
rm -rf src build bin coverage
mkdir src build bin coverage
echo 'int main() {return 0;}' > src/test.c
gcc -c -o build/test.o -g -fprofile-arcs -ftest-coverage src/test.c
gcc -o bin/test -g -fprofile-arcs -ftest-coverage build/test.o
./bin/test
cd coverage
gcov -o ../build ../src/test.c
As an addendum to this bug, if the absolute path to the object file was also
saved in the .gcda or .gcno file with the absolute path to the source file,
then one could generate coverage files using simply:
gcov ../build/test.gcna
(Currently one can specify the .gcna file this way, but one must run gcov in
the original build directory due to the relative source file path bug, and also
specify "-o build" since the object file path is not saved in the .gcna/.gcno
file.)
--
Summary: gcov fails to store the absolute path to the source
files
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov/profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david at coppit dot org
GCC build triplet: powerpc-apple-darwin8
GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28564
