linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Thompson <daniel.thompson@linaro.org>
To: Tom Rix <trix@redhat.com>
Cc: Nathan Chancellor <nathan@kernel.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Michal Marek <michal.lkml@markovi.net>,
	Nick Desaulniers <ndesaulniers@google.com>,
	linux-kbuild@vger.kernel.org, llvm@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] Enable clang tools for kernels build using gcc
Date: Tue, 28 Jun 2022 16:15:52 +0100	[thread overview]
Message-ID: <20220628151552.zkbvof7fyu3wtjqe@maple.lan> (raw)
In-Reply-To: <0478d832-d902-69ed-7c1c-4f19d942cddf@redhat.com>

On Tue, Jun 28, 2022 at 06:19:09AM -0700, Tom Rix wrote:
> The limitations of the compilation db are not limited to the kernel.
> 
> Why shouldn't the change be made in the llvm project ?

I'd rather answer the question why should it be in the kernel ;-).
That's somewhat easier to answer because the kernel does have some
unusual properties:

1. It makes heavy use of kernel command line options, especially
   when compared to most user space components where the default
   compiler flags are something very simple ("-g -O2" plus include
   directories).

2. The kernel provides it's own tooling to generate the compilation
   database. For example, if tools like codechecker added features to
   their front end to mitigate this problem[1] the kernel wouldn't
   benefit from them anyway.

3. Rules like `make clang-analyzer` generate *and* consume the
   compilation database in a single pass. That makes it impossible to
   run fixup tools between generating the database and consuming
   it.

However going back to the original question:
> Why shouldn't the change be made in the llvm project ?

clang can (and probably will) learn about some of the newer gcc options
over time. However that doesn't actually help much since all that
achieves is a game of whack-a-mole where clang has to constantly play
catch up or the tooling will break.

Some other aspects could be added to the various different projects that
use the compilation database that would improve things (better automatic
handling of --target for example). That sort of change should still
peacefully coexist with an approach based on gen_compile_commands.json
though.


Daniel.


[1] Currently they don't workaround it automatically. They just imply
    that you may have to "fine tune" compile_commands.json after
    generating it:
    https://codechecker.readthedocs.io/en/latest/usage/#step-7-fine-tune-analysis-configuration


> On 6/28/22 5:27 AM, Daniel Thompson wrote:
> > This patch set makes it possible to use clang based tools, such as
> > the clangd completion engine, regardless of our choice of compiler
> > for the actual kernel build.
> > 
> > Most of the fine details are included in the patch header for the
> > first patch (since we'd like them to appear in the kernel history so
> > they can help future archaeologists).
> > 
> > Daniel Thompson (2):
> >    clang-tools: Generate clang compatible output even with gcc builds
> >    Makefile: Enable clang-tidy and clang-analyzer for gcc builds
> > 
> >   Makefile                                    | 11 ++--
> >   scripts/clang-tools/gen_compile_commands.py | 71 ++++++++++++++++++++-
> >   2 files changed, 74 insertions(+), 8 deletions(-)
> > 
> > 
> > base-commit: a111daf0c53ae91e71fd2bfe7497862d14132e3e
> > --
> > 2.35.1
> > 
> 

      reply	other threads:[~2022-06-28 15:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-28 12:27 [PATCH 0/2] Enable clang tools for kernels build using gcc Daniel Thompson
2022-06-28 12:27 ` [PATCH 1/2] clang-tools: Generate clang compatible output even with gcc builds Daniel Thompson
2022-06-28 18:35   ` Nick Desaulniers
2022-06-28 12:27 ` [PATCH 2/2] Makefile: Enable clang-tidy and clang-analyzer for " Daniel Thompson
2022-06-28 13:19 ` [PATCH 0/2] Enable clang tools for kernels build using gcc Tom Rix
2022-06-28 15:15   ` Daniel Thompson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220628151552.zkbvof7fyu3wtjqe@maple.lan \
    --to=daniel.thompson@linaro.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=trix@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).