[PING**3] [PATCH] Force use of absolute path names for gcov

[Bernd Edlinger]

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.

At least in my real-word application this did the trick.
But I must admit the test case does not prove more than that
the option is not causing an error, especially because the
test suite uses absolute path names.

Is it now clear?


Thanks
Bernd.


> note libiberty has lrealpath to do (much of?) what you want.
> 
> nathan
>