gcc 8 creates gcno files that are unreadable by lcov

[berrange]

If a *.c file only contains some global constant the gcno file produced by the --coverage option is not readable by lcov

eg using gcc-8.0.1-0.16.fc29.x86_64 (forthcoming GCC 8 release currently in Fedora 29 rawhide)

[build@localhost tmp]$ cat t.c
const int a = 5;
[build@localhost tmp]$ gcc -Wall -Wextra -Werror -c ./t.c --coverage
[build@localhost tmp]$ lcov --capture --initial --directory .
Capturing coverage data from .
Found gcov version: 8.0.1
Scanning . for .gcno files ...
Found 2 graph files in .
Processing t.gcno
geninfo: ERROR: /tmp/t.gcno: reached unexpected end of file

The same works as expected with gcc-7.3.1-2.fc27.x86_64 on Fedora 27:

[sbose@p50 y]$ cat t.c
const int a = 5;
[sbose@p50 y]$ gcc -Wall -Wextra -Werror --coverage -c t.c
[sbose@p50 y]$ lcov --capture --initial --directory .
Capturing coverage data from .
Found gcov version: 7.3.1
Scanning . for .gcno files ...
Found 1 graph files in .
Processing t.gcno
TN:
Finished .info-file creation

Originally reported at https://bugzilla.redhat.com/show_bug.cgi?id=1552042

[oberpar]

Thanks for reporting. The issue actually appears to occur for any kind of source code compiled with GCC 8. I've added commit a5dd952 to address the changes introduced with GCC 8. Could you verify if this fixes the problem you are seeing?

[berrange]

I confirm that works for the simple demo program I was given by the original bug reporter. So that's good enough for me until someone complains about something else :-)

[marxin]

As being developer of GCOV in GCC, I would recommend to use intermediate format (-i) of gcov tool instead of reading of *.gc{da,no} files. Thanks for understanding.

[oberpar]

@marxin: GCOV's intermediate format looks promising. Can it be used to generate zero coverage data for .gcno files where no .gcda file is present? This is relevant for example for projects which consist of multiple executables, to get a total coverage view independent of the number of executables actually run during a test.

Some additional thoughts/observations:

• Adding the base directory path (current directory at the time of compilation) as a separate field to the output would be of massive value as it would make it easier to recreate absolute source code paths from relative paths.
• An option to have output on standard output instead of file would be nice (no more file operation/conflict in case of parallel processing)
• If the intermediate file format is intended for consumption by programs, additions to the format should be done in a backwards compatible way (counter example: addition of end_line_number to function data for example would have broken parsing relying on 3 CSV fields per line)
• Not sure if this occurs on upstream GCC, but I just noticed that running gcov -iab causes a core dump on GCC 7.2 (7.2.1 20170915 (Red Hat 7.2.1-2)). Using gcov -i alone on GCC 8 throws an assertion (8.0.1 20180222 (Red Hat 8.0.1-0.16)).

[marxin]

Thanks for the ideas, I've just created: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84846 which I will implement in next GCC release (9.1).

Not sure if this occurs on upstream GCC, but I just noticed that running gcov -iab causes a core dump on GCC 7.2 (7.2.1 20170915 (Red Hat 7.2.1-2)). Using gcov -i alone on GCC 8 throws an assertion (8.0.1 20180222 (Red Hat 8.0.1-0.16)).

Can you please provide an example of a source file that causes that?

[oberpar]

Excellent! Looking forward to those gcov improvements.
Regarding the gcc 7 segmentation fault: it appears to occur with any kind of source file:

$ gcc --version
gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ echo "int main() { return 0; }" > t.c
$ gcc t.c -o t --coverage
$ ./t
$ gcov -iab t.c
File 't.c'
Lines executed:100.00% of 1
No branches
No calls
Creating 't.c.gcov'
Segmentation fault (core dumped)

Edit: this is on s390x (big-endian) if that makes a difference.

[marxin]

Thanks again, useful feedback. I've just created:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84879

[PetterS]

This is great. Thanks! Will there be a new version released with this fix?

[oberpar]

It makes sense to release a new version of LCOV including this and other fixes. I'll have to see when I get the time to create it.

[marxin]

The GCC 8.1 has been released. A new version of LCOV would be great.

[JKorbelRA]

@oberpar, you've saved my day, thanks!

[marxin]

@marxin: GCOV's intermediate format looks promising. Can it be used to generate zero coverage data for .gcno files where no .gcda file is present? This is relevant for example for projects which consist of multiple executables, to get a total coverage view independent of the number of executables actually run during a test.

@oberpar This works now:

$ gcc --version
gcc (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc empty.c --coverage && ./a.out ; rm empty.gcda && gcov empty.c && cat empty.c.gcov
empty.gcda:cannot open data file, assuming not executed
File 'empty.c'
Lines executed:0.00% of 10
Creating 'empty.c.gcov'

        -:    0:Source:empty.c
        -:    0:Graph:empty.gcno
        -:    0:Data:-
        -:    0:Runs:0
        -:    0:Programs:0
    #####:    1:int foo(int argc)
        -:    2:{
    #####:    3:  if (argc % 2)
    #####:    4:    return 1;
        -:    5:  else
    #####:    6:    return 2;
        -:    7:}
        -:    8:  
        -:    9:int
    #####:   10:main(int argc, char **argv)
        -:   11:{
    #####:   12:  if (argc == 123)
    #####:   13:    __builtin_abort ();
    #####:   14:  else if(argc != 1111)
    #####:   15:    return foo (argc);
        -:   16:
    #####:   17:  return 0;
        -:   18:}
$ gcc empty.c --coverage && ./a.out ; rm empty.gcda && gcov -i empty.c && cat empty.c.gcov
empty.gcda:cannot open data file, assuming not executed
File 'empty.c'
Lines executed:0.00% of 10
Creating 'empty.c.gcov'

file:empty.c
function:1,0,foo
function:10,0,main
lcount:1,0
lcount:3,0
lcount:4,0
lcount:6,0
lcount:10,0
lcount:12,0
lcount:13,0
lcount:14,0
lcount:15,0
lcount:17,0

[marxin]

Adding the base directory path (current directory at the time of compilation) as a separate field to the output would be of massive value as it would make it easier to recreate absolute source code paths from relative paths.

Implemented in current trunk:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84846

An option to have output on standard output instead of file would be nice (no more file operation/conflict in case of parallel processing)

Likewise.

If the intermediate file format is intended for consumption by programs, additions to the format should be done in a backwards compatible way (counter example: addition of end_line_number to function data for example would have broken parsing relying on 3 CSV fields per line)

This should be done at consumer's side. Now we provide version which tools should follow and adjust parsing in a corresponding way.

Thus all feature requests mentioned in this issue are done at GCC's side.