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+aFSLS95qtpWQ0UjVU3wZ+svi2igLh_SoOqQec_Zwg7Mw@mail.gmail.com>
Date: Wed, 17 Dec 2025 11:16:37 +0100
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:39, Dmitry Vyukov <dvyukov@...gle.com> 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.

Yikes! I am trying to workaround this, but this is PITA.
Entries are not in order, + there are now multiple entries for the
same source file (yes, files include themselves). This is plain
broken, and hard to workaround. Even if I find the entry that is
correct, I can't really tell about it to a clang tool since it accepts
just the source file name, and there are multiple entries for the same
file name.

Does anybody see a reasonable way to undo what this commit is doing?

Thinking about this: I think included source files should be treated
as include files by anything, rather than added to the database. They
_are_ include files, and systems should handle include files already.