Nathan Chancellor <nathan@xxxxxxxxxx> writes: > On Tue, Nov 19, 2024 at 02:57:28AM +0000, Sam James wrote: >> Nathan Chancellor <nathan@xxxxxxxxxx> writes: >> >> > Hi Kostadin, >> > >> > Just a quick FYI off the bat, you only directed this to LKML, which is >> > basically like sending it into the void because very few people actually >> > read every message on LKML. I only caught it because I have a filter set >> > up for mentions of Clang and LLVM. I'd suggest adding at least the >> > Kbuild mailing list, which I have done now. I have also added Arnd >> > because I seem to recall him looking into how hard it would be to build >> > the kernel with C23. >> >> FWIW, scripts/get_maintainers.pl for stddef.h and types.h doesn't >> include kbuild -- maybe we should add that in. > > Yeah, it would be good to have someone own these files. Not sure it > makes sense for Kbuild to be it though, I merely suggested that since > the actual root cause of the error is more in Kbuild's realm. Yeah, I couldn't figure out who a better person would be either :| > >> I can reproduce it with `make defconfig` at >> 158f238aa69d91ad74e535c73f552bd4b025109c in Linus' tree with just `make >> V=1 -j$(nproc) -l$(nproc)` (i.e. no CFLAGS manipulation at all). >> >> ``` >> # CC drivers/firmware/efi/libstub/x86-5lvl.o >> gcc -Wp,-MMD,drivers/firmware/efi/libstub/.x86-5lvl.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/genera >> ted/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ >> -fmacro-prefix-map=./= -mcmodel=small -m64 -D__KERNEL__ -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -Wno-pointer-sign -Wno-address-of-packed-member -fno-asy >> nchronous-unwind-tables -Os -DDISABLE_BRANCH_PROFILING -include ./include/linux/hidden.h -D__NO_FORTIFY -ffreestanding -fno-stack-protector -D__DISABLE_EXPORTS -DKBUILD_MODFILE='"driv >> ers/firmware/efi/libstub/x86-5lvl"' -DKBUILD_BASENAME='"x86_5lvl"' -DKBUILD_MODNAME='"x86_5lvl"' -D__KBUILD_MODNAME=kmod_x86_5lvl -c -o drivers/firmware/efi/libstub/x86-5lvl.o drivers/fi >> rmware/efi/libstub/x86-5lvl.c >> In file included from ./include/uapi/linux/posix_types.h:5, >> from ./include/uapi/linux/types.h:14, >> from ./include/linux/types.h:6, >> from ./include/linux/kasan-checks.h:5, >> from ./include/asm-generic/rwonce.h:26, >> from ./arch/x86/include/generated/asm/rwonce.h:1, >> from ./include/linux/compiler.h:317, >> from ./include/linux/build_bug.h:5, >> from ./include/linux/init.h:5, >> from ./include/linux/efi.h:15, >> from drivers/firmware/efi/libstub/file.c:10: >> ./include/linux/stddef.h:11:9: error: expected identifier before ‘false’ >> 11 | false = 0, >> | ^~~~~ >> ``` >> >> -std=gnu11 certainly isn't there. > > Ugh, this is because drivers/firmware/efi/libstub does not use > KBUILD_CFLAGS from the rest of the kernel when targeting x86: > > $ sed -n '9,21p' drivers/firmware/efi/libstub/Makefile > # non-x86 reuses KBUILD_CFLAGS, x86 does not > cflags-y := $(KBUILD_CFLAGS) > > cflags-$(CONFIG_X86_32) := -march=i386 > cflags-$(CONFIG_X86_64) := -mcmodel=small > cflags-$(CONFIG_X86) += -m$(BITS) -D__KERNEL__ \ > -fPIC -fno-strict-aliasing -mno-red-zone \ > -mno-mmx -mno-sse -fshort-wchar \ > -Wno-pointer-sign \ > $(call cc-disable-warning, address-of-packed-member) \ > $(call cc-disable-warning, gnu) \ > -fno-asynchronous-unwind-tables \ > $(CLANG_FLAGS) > > This isn't the first time this peculiarity has bitten us :/ sticking > '-std=gnu11' in there should resolve that issue. > > arch/x86/boot/compressed/Makefile might need the same treatment. It > might make sense to introduce something like 'CSTD_FLAG := -std=gnu11' > then use that in the various places within the kernel that need it so it > can be consistently updated in the future whenever needed. I see that > flag in Makefile, arch/arm64/kernel/vdso32/Makefile, and > arch/x86/Makefile. This is the conclusion I just reached, although I'm struggling to figure out a nice place to put it without sprinkling it all over the place. I'm inclined to wait until kbuild folks weigh in so I don't do a lot of (trivial, but tedious) work that needs changing. As a hack, I've injected it into CLANG_FLAGS locally for now as it happens to appear in all the right places ;) > > Cheers, > Nathan thanks, sam
