https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82702

--- Comment #7 from Marco Castelluccio <mcastelluccio at mozilla dot com> ---
(In reply to Martin Liška from comment #6)
> Marco is right that it started with the mentioned revision. But let me start
> in more general context:
> 
> Consider virtual.cpp file that includes some standard header files.
> In that case gcov tool can be invoked with arbitrary file extension, because
> the file name is only used to find a proper gc{da,no} file:
> 
> $ gcov virtual.abcdef
> File 'virtual.cpp'
> Lines executed:100.00% of 9
> Creating 'virtual.cpp.gcov'
> 
> File '/home/marxin/bin/gcc2/include/c++/7.2.1/iostream'
> Lines executed:100.00% of 1
> Creating 'iostream.gcov'
> 
> Even if you rename virtual.gcno and virtual.gcda to x.gcno (x.gcda
> respectively):
> 
> $ gcov x.gcda
> File 'virtual.cpp'
> Lines executed:100.00% of 9
> Creating 'virtual.cpp.gcov'
> 
> File '/home/marxin/bin/gcc2/include/c++/7.2.1/iostream'
> Lines executed:100.00% of 1
> Creating 'iostream.gcov'
> 
> Because each gcno file contains locations for all function, it has exactly
> one source file and multiple header files. Here we come to intermediate
> format. I would prefer to generate same sets of .gcov files for both normal
> and intermediate format. I consider it more stable.
> 
> In your use case, I would suggest to support -l (--long-names) in
> intermediate format and use the path for content of intermediate file:
> 
> file:/home/marxin/bin/gcc2/include/c++/7.2.1/iostream.gcov
> 
> Doing so, one can concatenate all *.gcov files and use it for tools like
> lcov. I know it's behavior change, but can help if you have problem with
> number of files that need to be filled to lcov?

We are not using directly lcov, but a replacement we rewrote in Rust.
We can easily support reading from multiple gcov files instead of one
(actually, we already support it when llvm is used, since it doesn't support
the intermediate format).
The only problem is that it slows down parsing for large projects, which is
unfortunate since I guess the intermediate format was introduced to speed-up
parsing. We have a lot of included files (e.g. I just run it with one of our
gcno files and it generated 160
gcov files), so clearly opening and reading thousands of files is faster than
opening and reading hundreds of thousands.

Reply via email to