On Tue, 6 Oct 2026 at 17:14, Chuck Wolber <[email protected]> wrote: > > Stemming from some hallway track conversations with maintainers at LPC > 2026, I propose replacing gcov and kcov in the kernel with llvm-cov.
I know the origin of the discussion, and wanted to chat, but I guess that didn't happen and instead we get this proposal. It would have been good to understand the requirements of users of gcov and kcov (more below). > llvm-cov instruments at the AST which enables precise mapping back to > source code regardless of optimization level. > > We have a set of patches [1] that implements kernel based llvm-cov. They > need to be updated and some additional patches are required to address > some stubs that are missing noinstr annotation. But otherwise I should > be able to send a full set of patches (including taking on the > maintainer role) to remove gcov and kcov and replace it with llvm-cov in > fairly short order. The hallway chat was supposed to figure out if there's a way to bridge some of the gaps, but jumping the gun like this without having addressed the requirements of kcov users does not make any sense at all. As for gcov, llvm-cov was designed as a better replacement for gcov, so that makes more sense. Ok, well you made me untangle the most important differences between kcov vs. gcov/llvm-cov below so we have it for the record. > If there is a desire to take this in pieces or implement other > intermediate steps, let me know. Otherwise I can generate a monolithic > set all at once. > > [1] > https://lore.kernel.org/lkml/[email protected]/ llvm-cov is generally useful to have; llvm-cov is closest to gcov, so that might make sense to replace. KCOV, however, cannot be replaced by llvm-cov. KCOV isn't a coverage reporting tool for users, it's a low-overhead interface for fuzzers (syzkaller/syzbot and many others). llvm-cov has no equivalent of: - per-task and remote (kthread/softirq/USB/vhost) coverage collection (to avoid polluting coverage with concurrent tasks); llvm-cov counters are global and polluted by everything else running; - ordered PC traces (edge signal) and comparison operands (TRACE_CMP); - performance: a per-task mmap'd buffer reset with one store, vs. reading/resetting megabytes of global counters after every program; - GCC support (we may want to keep at least one GCC-supported coverage tool). It's also UAPI (include/uapi/linux/kcov.h), with existing users. syzkaller heavily relies on KCOV's features above to achieve good performance and coverage; there's no reasonable way today to migrate to anything else. As-is, NAK on removing KCOV. Consider replacing gcov with it. Thanks, -- Marco
