On Wed, Oct 7, 2026 at 2:09 AM Nathan Chancellor <[email protected]> wrote: > > On Tue, Oct 06, 2026 at 07:12:07AM -0700, Kees Cook wrote: > > And other architectures solve this problem by not wiping KBUILD_CFLAGS in > > the first place. :P So if we want to continue to accept the x86 exception > > (which I would argue is the actual problem), we likely need to, instead, > > construct an explicit export that is used to collect parsing control > > options so that it can be re-included here. Today, I can think of > > -fms-extensions besides -fexperimental-late-parse-attributes. > > > > KBUILD_PARSE_CFLAGS += -fms-extensions > > ... > > KBUILD_PARSE_CFLAGS += -fexperimental-late-parse-attributes > > ... > > export KBUILD_PARSE_CFLAGS > > KBUILD_CFLAGS += $(KBUILD_PARSE_CFLAGS) > > ... > > > > We already do something like this for CLANG_FLAGS, which, given > > -fexperimental-late-parse-attributes being Clang-specific, perhaps we > > ignore my -fms-extensions future-proofing, and just add it there, but > > it doesn't look like that is how scripts/Makefile.clang was intended to > > be used. > > I agree that fixing the x86 efistub to mirror other architectures is the > right fix for this particular instance of the problem (as you note this > is not the first time this has bitten us). However, we may want to > consider adding '-fexperimental-late-parse-attributes' to > CC_FLAGS_DIALECT as well so that the many other places in the kernel > that blow away KBUILD_CFLAGS won't have similar problems if > __counted_by_ptr happens to be used there, as this type of solution > might not always be possible. We could rename it to CC_FLAGS_PARSE or > something like that but I am not sure it is strictly necessary. > Ard,
What's the reason why x86 doesn't need the KBUILD_CFLAGS flags? Is there something that breaks things? -bw
