On Tue, Nov 19, 2024, at 05:15, Nathan Chancellor wrote:
> On Tue, Nov 19, 2024 at 02:57:28AM +0000, Sam James wrote:
>>
>> -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.
Could we revisit the decision to make x86 special here and
change it to use a modified KBUILD_CFLAGS like the other ones?
> 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.
I actually have a patch to make the entire kernel use -std=gnu2x,
but I never sent that because that requires gcc-9 or higher, and
has no real upsides: the main difference is the handling of 'bool'
types, and the std=gnu1x variant is simpler here because it avoids
using the compiler-provided "stdbool.h".
Arnd
