kcov: code coverage for compiled programs without recompiling them

DWARF debugging info instead of instrumented recompilation

The trick at the centre of kcov is the DWARF debugging information that compilers already emit. Rather than asking you to rebuild your program with coverage flags, the tool reads the debug data that a normal build leaves behind and uses it to work out which lines ran. That is the difference from most coverage tools, and it is why the tool fits C, C++ and Fortran projects where touching the build configuration is expensive. The project started as a fork of Bcov and has grown well past it. The supported platforms are FreeBSD, Linux and Mac OS, which is a hard boundary rather than a preference: the mechanism depends on the ELF and DWARF conventions those systems share. The stated languages are compiled languages plus Python and Bash.

One command produces HTML, Cobertura XML and JSON

Usage is short. The output directory comes first, then the executable, then any arguments for that executable:

kcov /path/to/outdir executable [args for the executable]

What lands in the output directory is lcov-style HTML that is generated continuously while the application runs, so a long test run shows results as it proceeds rather than at the end. Alongside the HTML, kcov writes Cobertura-compatible XML and generic JSON coverage information, which is the pair most CI services ingest. The README points out that this makes integration into CI systems straightforward rather than requiring a conversion step. The tool is written by Simon Kagstrom, and the project keeps its own web page and a set of documentation pages under doc/ for the individual integrations.

Two different filtering mechanisms, and they are not equivalent

Raw output tends to include far more than you want, with /usr/include being the usual example of a directory of no interest. kcov offers two ways to narrow it. The first is a plain string comparison over paths:

kcov --exclude-pattern=/usr/include --include-pattern=part/of/path,other/path \
      /path/to/outdir executable

That variant includes everything containing part/of/path or other/path and excludes everything containing /usr/include. The second set of options does proper path lookups rather than substring matching:

kcov --include-path=/my/src/path /path/to/outdir executable
kcov --exclude-path=/usr/include /path/to/outdir executable

The distinction is easy to miss and matters in practice, because a substring rule can match a directory you did not intend to include, while path rules match the location itself.

Merging several runs into a single report

Test suites are often split across machines or configurations, and kcov can combine results from earlier runs into one report. The mode is switched on with the merge flag, followed by an output path and one or more directories holding previous runs:

kcov --merge /tmp/merged-output /tmp/kcov-output1 /tmp/kcov-output2
kcov --merge /tmp/merged-output /tmp/kcov-output*    # With a wildcard

The wildcard form is what makes this practical in CI, since it lets a script pick up every run directory that exists rather than listing them. Coverage figures from a merged report then cover the union of what each run touched, which is how a team gets one number for a suite that no single job executes in full.

Integration targets and the docs that cover each one

kcov is designed to sit inside a CI pipeline rather than to be a standalone report generator. The README names Travis CI and GitHub Actions paired with coveralls.io and codecov.io as the main combination, and also mentions Jenkins, SonarQube and GitLab CI as supported hosts. Each has its own page under doc/, covering the coverage gutters feature in VS Code, the Travis CI plus coveralls setup, the Travis CI plus codecov setup, the Jenkins integration, using kcov together with SonarQube, and separate pages for GitHub and GitLab. The repository also carries a travis/ directory, a Dockerfile and a CMakeLists.txt, so the CI setup is part of the source rather than something described only in prose.

Building from source, or using the kcov/kcov image

Installation has two documented paths. The INSTALL.md file in the repository root holds the build instructions for building kcov yourself, and the README points to the official Docker image on Docker Hub, with the note that the kcov/kcov image covers releases since v31. The Dockerfile at the root of the repository is a multi-stage build: it takes the base operating system and version as build arguments, installs the toolchain for Alpine or Debian, configures with CMake using the Ninja generator, and installs the result into a slim runtime image that copies the kcov binary and its documentation from the builder stage. Licence terms are GPL-2.0, with COPYING and COPYING.spdx in the root. The repository is not archived and the last push was on 2026-09-30, while tagged releases move less often: v44-pre-test3 in January 2026, v43 in July 2024 and v42 in August 2023.

Editorial conclusion

kcov suits projects on FreeBSD, Linux or Mac OS whose build system cannot easily add coverage instrumentation flags, and teams that want lcov-style HTML, Cobertura XML and JSON output from one run. It does not suit Windows targets, which the platform list does not include, and it does not replace instrumentation when you need branch coverage precision from a compiler that can produce it. Before adopting, check the INSTALL.md build steps for your distribution, or use the kcov/kcov Docker image, which covers releases since v31.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. SimonKagstrom/kcov on GitHub