Re: [PROPOSAL] Replace gcov and kcov with llvm-cov

["Chuck Wolber" <chuck@wolber.net>]

On Wed, Oct 7, 2026, at 2:30 AM, Masami Hiramatsu wrote:
> On Tue, 06 Oct 2026 16:27:11 +0000, Chuck Wolber <chuck@wolber.net> wrote:
>> On Tue, Oct 6, 2026, at 4:10 PM, Marco Elver wrote:
>> > On Tue, 6 Oct 2026 at 17:14, Chuck Wolber <chuck@wolber.net> wrote:
>
>> >> 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/20240905043245.1389509-1-wentaoz5@illinois.edu/
>> >>
>> > >> > llvm-cov is generally useful to have; llvm-cov is closest to
>> > >> > gcov, so that might make sense to replace.
>>
>> Swapping llvm-cov for gcov to start with is pretty straightforward,
>> so I can aim my initial patch set there.
>
> Hmm, is it necessary to remove gcov? Would it be difficult to simply
> add support for llvm-cov and enable (make kconfig selectable) one or
> the other depending on the compiler?

Not strictly necessary, no. And what you are describing is what our
original patches do.

The concern was why we would want to have three separate code coverage
tools in the kernel. Each has their own way of doing things, and they
can all live together in the kernel harmoniously.

But the concern was raised so I am trying to find a way forward.

The llvm-cov approach gives results that are reliably tied to actual
lines of source, so that is the one I reflexively reach for any time I
need code coverage. I am at a loss (but definitely willing to be
educated) as to what value gcov style coverage provides in comparison.

I also found some interesting possibilities using intrinsics to enable
boot time tracing with llvm-cov. That is, of course, experimental and
not something I am considering for the intial patch-set. But it got me
thinking about broader configurability that supports more granular forms
of coverage that _may_ address kcov needs in the long term.

I have been working on this off-and on for a few years and still really
want to see this idea succeed. Any guidance on a workable path forward
would be greatly appreciated.

Another option, proposed by Sasha Levin[1], was to use a single
/sys/kernel/debug/coverage interface, quoting him here:

"To clarify, are you suggesting that we'll have something like a single
 /sys/kernel/debug/coverage interface that is producing the same structured
 output whether we use gcov or llvm?"

I am not sure it is feasible to use the same structured ouput, but it
would isolate things down to a single interface with KConfig knobs being
used to select which coverage data one can expect to find there.


[1] https://lore.kernel.org/lkml/aba_HgSbzLGm6VBQ@laps/


Thank you,

..Ch:W..