On Wed, 07 Oct 2026 04:17:42 +0000, Chuck Wolber <[email protected]> wrote: > On Wed, Oct 7, 2026, at 2:30 AM, Masami Hiramatsu wrote: > > On Tue, 06 Oct 2026 16:27:11 +0000, Chuck Wolber <[email protected]> wrote: > >> On Tue, Oct 6, 2026, at 4:10 PM, Marco Elver wrote: > >> > On Tue, 6 Oct 2026 at 17:14, Chuck Wolber <[email protected]> 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/[email protected]/ > >> >> > >> > >> > 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) <[email protected]>
