linux-kernel - Re: [GIT PULL] kbuild changes for v6.19

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+bsiPfmL-yV99mLCA4n7ukYwS-6E7kTcLg1EOxOQ_cZjg@mail.gmail.com>
Date: Wed, 17 Dec 2025 17:39:25 +0900
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Nicolas Schier <nsc@...nel.org>, patso@...ewhatevs.io, 
	Justin Stitt <justinstitt@...gle.com>, eddyz87@...il.com, 
	Linus Torvalds <torvalds@...ux-foundation.org>, linux-kbuild@...r.kernel.org, 
	linux-kernel@...r.kernel.org, regressions@...ts.linux.dev
Subject: Re: [GIT PULL] kbuild changes for v6.19

On Wed, 17 Dec 2025 at 09:32, Nathan Chancellor <nathan@...nel.org> wrote:
>
> On Wed, Dec 17, 2025 at 05:16:02PM +0900, Dmitry Vyukov wrote:
> > On Mon, 1 Dec 2025 at 16:38, Nicolas Schier <nsc@...nel.org> wrote:
> > > Pat Somaru (1):
> > >       scripts/clang-tools: Handle included .c files in gen_compile_commands
> >
> > /\/\/\/\/\/\/\
> >
> > This commit breaks invocation of clang tools for me.
> >
> > For example I now have this fake entry for mock_uncore.c which
> > pretends to produce intel_uncore.o (along with 2 other commands which
> > produce the same object file):
> ...
> > An attempt to invoke a clang tool using this database legitimately
> > fails with the following errors (the file is not supposed and can't
> > compile on its own):
> >
> > clang-tool: drivers/gpu/drm/i915/selftests/mock_uncore.c: exit status 1
> > drivers/gpu/drm/i915/selftests/mock_uncore.c:47:2: error: call to
> > undeclared function 'ASSIGN_RAW_WRITE_MMIO_VFUNCS'; ISO C99 and later
> > do not support implicit function declarations
> > [-Wimplicit-function-declaration]
> >    47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
> >       |         ^
> > drivers/gpu/drm/i915/selftests/mock_uncore.c:47:39: error: use of
> > undeclared identifier 'nop'; did you mean 'nopv'?
> >    47 |         ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
> >       |                                              ^~~
> >       |                                              nopv
> > /arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
> >    71 | extern bool nopv;
> >       |             ^
> > drivers/gpu/drm/i915/selftests/mock_uncore.c:48:2: error: call to
> > undeclared function 'ASSIGN_RAW_READ_MMIO_VFUNCS'; ISO C99 and later
> > do not support implicit function declarations
> > [-Wimplicit-function-declaration]
> >    48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
> >       |         ^
> > drivers/gpu/drm/i915/selftests/mock_uncore.c:48:38: error: use of
> > undeclared identifier 'nop'; did you mean 'nopv'?
> >    48 |         ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
> >       |                                             ^~~
> >       |                                             nopv
> > /arch/x86/include/asm/hypervisor.h:71:13: note: 'nopv' declared here
> >    71 | extern bool nopv;
> >       |             ^
> > 4 errors generated.
> > Error while processing /drivers/gpu/drm/i915/selftests/mock_uncore.c.
> >
> >
> > What am I doing wrong?
>
> Nothing. As you note, ASSIGN_RAW_WRITE_MMIO_VFUNCS is defined in
> drivers/gpu/drm/i915/intel_uncore.c but it is used in
> drivers/gpu/drm/i915/selftests/mock_uncore.c, which is not designed to
> be built standalone. We could potentially move
> ASSIGN_RAW_WRITE_MMIO_VFUNCS into a common header to avoid this but I
> think I would rather just revert 9362d34acf91, as I already figured that
> this was going to be fragile:
>
>   https://lore.kernel.org/20251007163338.GA547361@ax162/
>
> I would rather discourage including .c files if folks want clangd to
> work properly since this seems fundamentally unsolvable if developers
> have written .c files in this manner. I am open to other thoughts
> though.

I am not sure what other clang tools are doing, and why they need
this. But FWIW my clang tools don't need it at all. They would index
all files, get source files from AST (which would include included .c
files as well), and work with that index. So they natively "see" and
understand all included .c files.