ggcov / ggcov

A simple GUI for browsing C test coverage data from programs built by gcc

ggcov

This is a simple GUI for browsing C test coverage data gathered by programs instrumented with gcc --coverage. Hence it's a graphical replacement for the gcov program that comes with gcc. It can also generate a static HTML report like the lcov program.

I wrote this program because I was sick of crappy text mode coverage results, having been spoilt some years earlier by the PureCoverage GUI.

Using ggcov

To use ggcov:

• Instrument your code by building with gcc --coverage. This will generate some .gcno files.
• Run your tests. This will generate some .gcda files.
• Invoke ggcov with the filename of an executable, or with a source directory, or with one or more source (.c, .cxx etc) filenames. Ggcov will find and read the .gcno, and .gcda files and display data for you in some nice GUI windows.

Ggcov also comes with alternate ways to view coverage information.

• ggcov-html generates a directory full of static HTML, like lcov.
• git-history-coverage shows coverage correlated to recent git commits, useful for CI.
• tggcov emits text output like gcov, and has a mode to generate Coberatura format coverage reports, useful for CI.
• ggcov-run is a utility useful for running instrumented programs in directories other than their build directory, or on a different machine.
• ggcov-web is a PHP application for interactively displaying coverage data in a browser (superceded by ggcov-html).

Ggcov supports a powerful set of suppression primitives, so you can avoid your coverage numbers being under-reported due to code which you know will never execute.

Limitations

The gcc+ggcov system has several limitations and gotches of which you should be aware.

• Gcc will add enough instrumentation to .gcno files for ggcov to tell that certain arcs between basic blocks are actually calls to other functions, but there isn't enough information to tell which other functions are being called, even when this is known at compile time. Ggcov attempts to extract this information after the fact by scanning the code in object files and correlating that with the .gcno files. This process can fail for several reasons, which will result in the data in the Call Graph and Call Butterfly windows being absent or incomplete, and the data in the Calls window not having the function names. Reasons for the include:

  • the object files are missing

  • the object files are for an architecture which is not yet supported by ggcov for the purposes of this feature (at time of writing, this feature is only supported on Linux x86 and x86-64).

  • calls through function pointers or C++ virtual functions are not known at compile time and cannot be calculated using the data available to ggcov.

• Code which puts multiple basic blocks on a line may not give the line coverage numbers you expect. In particular, when an entire loop is squashed into a single line, ggcov will report the number of times the loop ran plus one for each time the loop started, instead of the number of times the line as a whole ran.

• The Call Graph window uses a very primitive graph layout algorithm and may well loop or crash when given used on some programs.

Greg Banks 27 June 2020.

ggcov's Issues

Arm64 support

Hi Greg

I have a wishlist bug in Debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871696) where someone would like arm64 support.
I see that it would require a port of src/cov_i386.C to src/cov_arm.C ; how much work do you think this would be? Any good sources you'd recommend on ISA details relevant to the problem?

Best regards
Alastair

Port to GTK3

Hi Greg
Happy New year !

Debian is transitioning to drop GTK2 support, and hence ggcov will be dropped unless its moved forward to GTK3:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885736

Have you any plans for a port, or any idea how much work is involved?

Best regards
Alastair

0.11 Release Tracker

This ticket is for tracking progress towards a 0.11 release of ggcov.

Summary

No work yet.

Remaining Work

Not finalized, but here are the candidates for work in 0.11

• #7 Support DWARF versions 3, 4, and 5.
• #2 Support call scanning on ARM64 platforms
• #3 Port to GTK3

Switch from ruby-mustache to ctemplate

The new ggcov-html program in ggcov 0.10 generates static HTML by expanding templates using the mustache program. Mustache is a Ruby program, so a dependency on it brings in a whole new ecosystem which might be unfamiliar and unwelcome to ggcov users, who are by definition C/C++ users. Mustache was [inspired by] an older templating system from Google known as ctemplate and copies its syntax closely. Ctemplate is in C++ and does not involve any Ruby dependency. Preliminary research shows it's available on many Linux platforms.

This ticket is for

• researching platform support for ctemplate
• if sufficiently widely available, switch ggcov-html to using it.

ggcov crashes when clicked on range option

When I run ggcov and click on range option I get the following error:

ggcov: ptrarray.H:173: T* ptrarray_t::nth(unsigned int) const [with T = cov_function_t]: Assertion `i < len' failed.
Aborted (core dumped)

fix build with recent binutils

the build with recent binutils (2.34) is fixed with the attached patch.

Note that the package is not ready for GCC 9 and GCC 10.

--- ggcov-0.9+20190314.orig/src/cov_bfd.C
+++ ggcov-0.9+20190314/src/cov_bfd.C
@@ -330,11 +330,11 @@ cov_bfd_t::dump_reloc(unsigned int idx,
unsigned char *
cov_bfd_section_t::get_contents(bfd_size_type *lenp)
{

• asection *sec = (asection *)this;

• const asection *sec = (asection *)this;
  bfd_size_type size;
  unsigned char *contents;

• size = bfd_section_size(sec->owner, sec);

• size = bfd_section_size(sec);
  contents = get_contents(0, size);
  if (lenp != 0)
  *lenp = size;

Cleanup fuzzy C/C++ boundaries

ggcov was originally written a very long time ago in C and gradually ported to C++. This has left a lot of anomalies where, for example, C++ source is in a file with a .c extension. Modern compilers are getting pickier about this sort of thing, and ggcov needs to clean up lax usage.

Also, these days ggcov is developed with the source code on a underlying case-preserving but case-insensitive filesystem. However ggcov uses the .C extension for C++, which is a case alias of the .c extension for C. This has already caused several ugly issues where code compiled in the development environment did not compile downstream. The casecheck.pl script was added to mitigate this problem, but the real long term solution is to eliminate case aliases by using a different set of extensions for C++ code. For consistency with my more recent projects I'm going to choose .cxx and .hxx.

Support DWARF versions 3, 4, 5

Class cov_dwarf2_filename_scanner_t implements scanning of DWARF debug information to find source filenames from an executable. This is a good usability feature for ggcov and needs to keep working. Unfortunately this code is very old and will only work on DWARF v2 information. The DWARF standard has since gone through versions 3, 4, and 5 and modern compilers support all those versions and emit modern ones by default. Ggcov needs to move with the times and support all DWARF versions found in the field.

Switch from PNG to SVG in static HTML

The new ggcov-html program available in ggcov 0.10 generates annotated source code with basic block flow diagrams in PNG format. Obviously this results in some bad appearance artifacts when the browser window containing the annotated source is scaled up or down by a lot.

This ticket is to switch ggcov-html's flow diagrams to a vector format with wide browser support like SVG.

ggcov fails on gcc 12

Hi

It appears the gcov format parsing needs to be updated for gcov 12, as it fails on gcc 12.*

regards
Alastair

Fails with gcc7.1

Hi Greg
I've been testing ggcov with gcc 7.1 and it fails. It looks like the gcno / gcna format have changed with the latest release.
Any plans on updating?

regards
Alastair

Use C++11 features

C++11 has been around and supported in compilers for many years now; there have been C++14, C++17 and C++20 standards efforts since then. C++11 is the default on modern compilers, and the ggcov code has already been fixed in very minor ways to compile with it (e.g. not concatenating string literals in a way which is ambiguous in C++11). More significantly, recent experience shows that functioning C++11 support is available in the LTS releases for every major Linux vendor, with the sole exception of RHEL6 which will fall out of support in about 4 months.

This ticket is for modernizing the ggcov codebase to use non-backwards-compatible C++11 features where it makes sense. In particular, use of C++11 ranged iteration is very attractive. This will mean that C++11 support is required to build ggcov.

Support needed for gcc8 changes

Gcc8.1 has been released, and breaks ggcov :-(

A summary of the changes in gcno file format are given in a changeset for lcov:
linux-test-project/lcov@a5dd952

Remove CLI dependency on glib and popt

The CLI portions of ggcov, and the core code, were originally written as part of the GTK-based GUI at a time when the STL on Linux was very buggy and feature-deficient and good free third-party libraries like Boost did not exist. Thus it uses a lot of data structures from the GNOME glib and popt libraries wrapped in a custom C++ wrapper for improved type safety and idiomaticity. Time has passed and conditions changed. Now better options are available and reliable. Also the dependency from the CLI programs on glib and popt are counterproductive, because they drag in a large fraction of the GNOME libraries.

This ticket is for modernizing the ggcov CLI and core codebases to eliminate uses of glib and popt, building on the preliminary work in the std-data-structures and std-data-structures2 branches.

Remove support for obsolete compilers and formats

The core of ggcov was written nearly twenty years ago and still contains explicit support for compiler versions and file formats not seen in the field for many years. This code is effectively untestable because the environment it's meant to support cannot be replicated anymore. Thus it prevents significant refactoring or improvement of the surrounding code.

This ticket is for researching which of those compilers versions and file formats are still supported by the community, and removing support for those that aren't.

The working definition of "supported" we'll use is: available as a standard or extension (e.g. "EPEL" or "testing") package in a Long Term Support release from a major commercial Linux vendor (plus Debian) which is in a lifecycle phase where it is receiving security updates. So for example RedHat's Extended Life Phase is out but their Maintenance Support Phase 2 is in.

Feature	Status
gcc 2.96	?
gcc 3.*	?
gcc 4.*	?
gcc 5.*	?
gcc 6.*	?
gcc 7.*	supported
gcc 8.*	supported
gcc 9.*	supported
gcc 10.*	supported
.bb, .bbg, .da files	?
stabs debug format	?