From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 474C2CA5FFF for ; Wed, 7 Oct 2026 04:51:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:MIME-Version: Content-Transfer-Encoding:Content-Type:References:In-Reply-To:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YfZUOyUfb3wd5BZD5cwO1pIKgms+v7U6RGWL1mBY3dE=; b=USk/9Pxxy/DKFRujSNrjE2CfOK 0WURw9OoUkeOAB9SNQ6/vLc9eloSotDOL+YQabtRb79THvQUxgTc/JZrY8xCkHdGFcCLAkgGmMvxm 0nkXY0jQzEgwK8dNMQWT6ZBbM2uVxBG+6GW5ipwGo9GfC5xv7l0qulx2qmGx7Kid0IAHdR15AUNTY 4WyZU8mjZrf6yML8m4D44kuaAxCL85r07jOeZ1x73rOnQQ9UiTtFR361zGa/x0Tv3/Jfy1nR9t2aJ XT1xIpxICfGNIoIkjnSSKnw5RHOiPbUi/5J+mMVmdWSbGggt+no4imlc52Lsjy8bD3txrqmUzPmJH IT1nNvRA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xEJcS-00000001hbh-1DQs; Wed, 07 Oct 2026 04:51:08 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xEJcQ-00000001hbW-1Lzy for linux-um@lists.infradead.org; Wed, 07 Oct 2026 04:51:06 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id B096E44003; Wed, 7 Oct 2026 04:51:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 601511F0089B; Wed, 7 Oct 2026 04:50:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791348663; bh=YfZUOyUfb3wd5BZD5cwO1pIKgms+v7U6RGWL1mBY3dE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=lRq/cv3JeDXOU7UAotnpyWzkc5IyRNKfUTmp/K9D+Lvv0ReiYLI3VHi2G6fPb9Fe6 7hMSRWZiJzioAzkgYeQ4OZlo46uV7DUJzNK2T/BSEGGy8WuhUDq7EGYxcz6mf1AzO1 edgEZI5EJtHT2BuB0W6X9LHDsshHEijdDUpm+qzeHYEQ4f4TLLsoDqqregETx9niGK 6VutLbFMjj+zfDEKx43onqPWM3GpcsQStQG0HYQ6GlJQkLLe7R88X2ck4BZu+ONvqc 7eCfuniZGMkIRBclQDfx2EL8TK1Cidt28FtIWDSMXLSMYWKmrELbdvaeU+ORXcvP6L uzWlvJbA5sDeA== From: Masami Hiramatsu (Google) To: chuck@wolber.net Cc: Masami Hiramatsu , Marco Elver , kasan-dev@googlegroups.com, nathan@kernel.org, akpm@linux-foundation.org, anton.ivanov@cambridgegreys.com, oberpar@linux.ibm.com, ardb@kernel.org, arnd@arndb.de, bhelgaas@google.com, bp@alien8.de, dave.hansen@linux.intel.com, dvyukov@google.com, hpa@zytor.com, jinghao7@illinois.edu, johannes@sipsolutions.net, jpoimboe@kernel.org, justinstitt@google.com, kees@kernel.org, kent.overstreet@linux.dev, linux-arch@vger.kernel.org, linux-efi@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-um@lists.infradead.org, llvm@lists.linux.dev, luto@kernel.org, marinov@illinois.edu, masahiroy@kernel.org, maskray@google.com, mathieu.desnoyers@efficios.com, mingo@redhat.com, morbo@google.com, Nick Desaulniers , "Paul E. McKenney" , richard@nod.at, Steven Rostedt , samitolvanen@google.com, tglx@linutronix.de, tingxur@illinois.edu, tyxu@illinois.edu, wentaoz5@illinois.edu, x86@kernel.org, peterz@infradead.org, Sasha Levin , Aleksandr Nogikh , Taras Madan , Alexander Potapenko Subject: Re: [PROPOSAL] Replace gcov and kcov with llvm-cov Date: Wed, 07 Oct 2026 04:50:47 +0000 In-Reply-To: References: 00ed0b57-ad05-4c5d-b152-7c81df94b23a@app.fastmail.comCANpmjNOaykC4McAj=gZghqPSQc9aGBP_CjgKmp3n2yjeJTxDSA>@mail.gmail.com<41913a77-5c57-4967-8166-765dd5dde1bf@app.fastmail.com 20261007023045.04BD71F0089B@smtp.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-Id: <20261007045050.601511F0089B@smtp.kernel.org> X-BeenThere: linux-um@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-um" Errors-To: linux-um-bounces+linux-um=archiver.kernel.org@lists.infradead.org On Wed, 07 Oct 2026 04:17:42 +0000, Chuck Wolber wrote: > On Wed, Oct 7, 2026, at 2:30 AM, Masami Hiramatsu wrote: > > On Tue, 06 Oct 2026 16:27:11 +0000, Chuck Wolber wrote: > >> On Tue, Oct 6, 2026, at 4:10 PM, Marco Elver wrote: > >> > On Tue, 6 Oct 2026 at 17:14, Chuck Wolber 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)