On 06/02/2017 10:43 AM, Bernd Edlinger wrote:
On 06/02/17 13:35, Nathan Sidwell wrote:
On 06/01/2017 03:24 PM, Bernd Edlinger wrote:
This is a gcc option that converts relative
path names to absolute ones, so that gcov can
properly merge the line numbers in projects
where different relative path names may refer
to the same source file.
Thanks. From reading the patch though, I didn't grok that intent. The
patch itself suggests gcov simply fails with relative paths and
directories. What you're really trying to do is find the canonical
path, which happens to be absolute. But you're not doing that either --
you're concatenating the relative path to cwd. How is that helping? Is
it when you have a mixture of absolute and relative paths?
Yes, let me explain why I need that.
Recently I wanted to get the line-coverage of an application
I work with. The problem I faced is, that different modules
invoke gcc in different working directories, and there are
things like -I ../include in one place, and -I ../../Core/include
in other places, so ../include/test.h and ../../Core/include/test.h
may or may not refer to the same file. Also several module tests
use a separate folder, and a file like "./Test1.cpp" may actually
exist in several directories, but gcov does not find the sources,
in this scenario and copying everything to a single directory is
not a good solution either.
So in the end I want to run the different module tests etc.
and let gcov collect and merge all the coverage data, and of course
find the right source files for the report, without substantially
changing the application's original make files.
Some other cases:
1) 'bob/../foo.c' and 'baz/../foo.c'?
2) 'bob/foo.c' and 'baz/foo.c' where baz is a symlink to bob?
3) combinations of #2 and #3 such that textual elision of .. gets you to
a different place than resolving symlinks.
Given all that complexity, wouldn't it be better to tell gcov where
relative paths should start? (perhaps encoding in the file?). It does
need access to the source directories.
gcov.c already has a function named canonicalize_name that does exactly
what I need, i.e. elide /./ and collapse ../bob/../foo.c
to ../foo.c and even do something with symbolic links, however my app
does not use any sym-links so I did not really test that part.
But this function works only under the assumption that relative file
names start always from the current working directory.
So what my patch does, is leave absolute file names untouched and
prepend the current working directory to all file names that do
not look like absolute file names. Thus it does not claim to
canonicalize the file name, but only to make it an absolute file
name. But now gcov's canonicalize_name is actually able to
do the rest.
Ok, that makes sense, thanks for the explanation.
+Compile the source files additionally with @option{-fprofile-abs-path}
+to create absolute path names in the @file{.gcno} files. This allows
+@command{gcov} to find the correct sources in projects with multiple
+directories.
I think the second sentence could be better. It's not that the sources
are in different directories, it's that the compiler is invoked with
different working directories. How about
'This allows @command{gcov} to find the correct sources in projects
where compilations occur with different working directories.'
modify as you see fit.
gcov_write_filename (const char *filename)
+{
+ char buf[1024];
+ size_t len;
Ew. (a) bad fixed length (b) bad stack frame bloat. Please use malloc
& MAX_PATH_LEN (or whatever the right #define is).
+ if (profile_abs_path_flag && filename && filename[0]
Can filename ever be null here? Can it ever be the empty string?
+ if (getcwd (buf, sizeof (buf) - len - 1) != NULL)
This is going to getcwd on every file (most likely). Isn't this already
available somewhere?
nathan
--
Nathan Sidwell
