I've given this some more thought and came up with a possible
alternative solution that doesn't require paths to be absolute:
For a given source file x.c, gcov requires x.c (main source),
x.gcno (static coverage meta data) and x.gcda (dynamically created
coverage data) to work. x.gcno may refer to further source files. To
find these files the corresponding paths need to be either absolute or
gcov must be called from gcc's current working directory during
compilation (which always should be $(objtree)).
Currently these files are placed like this:
sysfs:
x.gcda
x.gcno -> symbolic link to $(objtree)/rel/path/x.gcno
x.c -> symbolic link to $(srctree)/rel/path/x.c
objtree:
x.gcno
srctree:
x.c
Instead, kbuild could be modified to create links to x.gcda in
$(objtree) like this:
sysfs:
x.gcda
objtree:
x.gcno
x.gcda -> symbolic link to /sys/kernel/debug/gcov/rel/path/x.gcda
srctree:
x.c
gcov could then be called like this:
cd $(objtree)
gcov -o rel/path/ $(srctree)/rel/path/x.c
Would this be an acceptable approach? Also, for automated collection of
coverage data, there must be some algorithm to find the source file for
a given .gcda file. Is the assumption correct that the "rel/path/" part
is the same for $(srctree) and $(objtree), i.e. can the source file
be derived like this?:
$(objtree)/rel/path/x.o -> $(srctree)/rel/path/x.c
Alternatively, kbuild could also create a link to x.c in $(objtree),
though I'm not sure if that wouldn't have side effects like e.g. naming
conflicts with generated .c files in $(objtree).
--
