geninfo: preserve-paths makes gcov to fail for long pathnames

[iignatev]

geninfo uses '--preserve-paths' gcov option whenever gcov supports it, this
forces gcov to use a whole pathname as a filename for .gcov files. So in cases
of quite large pathnames, gcov isn't able to create .gcov files and hence
geninfo can't get any data. The fix removes '--preserve-paths'.

Signed-off-by: Igor Ignatev igor.v.ignatiev@gmail.com

[iignatev]

I wasn't able to find any reasons why '--preserve-paths' might be needed, so I decided to remove it. If there are cases where it helps, we can make it opt-out or opt-in.

[oberpar]

I don't think this will work. Take the following example:

File subdir/test.c:

int fn()
{
        return 0;
}

File test.c:

#include "subdir/test.c"

int main()
{
        return fn();
}

To get coverage data:

$ gcc test.c -o test --coverage
$ ./test
$ gcov test.gcda
File 'test.c'
Lines executed:100.00% of 2
Creating 'test.c.gcov'

File 'subdir/test.c'
Lines executed:100.00% of 2
Creating 'test.c.gcov'

$ ls *.gcov
test.c.gcov

Note how the second data file has overwritten the first one due to the same basename. Without --preserve-paths, lcov is unable to get data for both files.

Even when your proposed change is made optional, there's no way to detect a situation where a gcov file was overwritten, resulting in silently lost coverage data.

[iignatev]

right, now I see why preserve-paths is needed. there are however cases where you know that there are no files with the same name in a whole project, e.g. in HotSpot, all .c/.cpp, have a unique filename unless they are platform specific, but one of them is used during compilation, and this is enforced/guaranteed by the build process. so I still see value in adding a geninfo flag to disable preserve-paths.

[xaizek]

Related paragraph from man gcov:

-x
--hash-filenames
    By default, gcov uses the full pathname of the source files to to create an
    output filename.  This can lead to long filenames that can overflow
    filesystem limits.  This option creates names of the form
    source-file##md5.gcov, where the source-file component is the final filename
    part and the md5 component is calculated from the full mangled name that
    would have been used otherwise.

So maybe you want to just enable this option (always?).

[iignatev]

@xaizek, good suggestion. I think hash-filenames should be used instead of preserve-paths if it's available.

[oberpar]

Applied as 42b55f5 with some whitespace-fixes. Thank you for your contribution!

[ejbrenes]

Is this already fixed? Is it possible to do something at lcov level to tell gcov to use hash-filenames option?
I am using lcov 2.0 and facing errors because of long file names.

[hartwork]

@ejbrenes the related commit 42b55f5 mentioned above is included in LCOV >=1.14 with regard to Git history. If you're still experiencing issues despite of that, please check back with latest Git master and if that's still found broken for your scenario please create a new issue with (1) sufficient details on your environment — operating system, distro release, used compiler if applicable etc — and (2) a minimal reproducer. That's your best chance for a soon fix, I believe.

PS: The last sentence of #390 (comment) should also be noted, with regard to expectations on a time line, I'm not a maintainer here, just helping out a bit.

[henry2cox]

As @hartwork notes, above: newer versions of lcov (2.1 and newer) use a somewhat different geninfo infrastructure, and may (or may not) work better in your application.
Please download the latest release (2.3) and see if that addresses your issues. If not: please extract a testcase which exhibits the issue and file a new bug report. (Or you can reopen this one, if you prefer.)
Thanks
Henry