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

[Masami Hiramatsu (Google) <mhiramat@kernel.org>]

On Wed, 07 Oct 2026 04:17:42 +0000, Chuck Wolber <chuck@wolber.net> wrote:
> 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.

OK, let me check it.

>
> 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 agree with llvm-cov is better than GCOV. But since gcc users can
NOT use this feature, for checking code coverage in the kernel,
we still need to keep it for gcc users.

> 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.

Ah, that's an interesting idea :)

>
> 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.

Yeah, that soulds reasonable for me.

Thank you,

>
>
> [1] https://lore.kernel.org/lkml/aba_HgSbzLGm6VBQ@laps/
>
>
> Thank you,
>
> ..Ch:W..

-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>