Re: [PATCH v2] x86/boot: define CC_HAVE_ASM_GOTO

[Borislav Petkov]

On Thu, Sep 27, 2018 at 03:17:41PM -0700, Nick Desaulniers wrote:
> That's another case that I look at and wonder "why does this exist?"
> The _SETUP guard exists in only one place:
> $ grep -rP 'ifdef\s+_SETUP'
> arch/x86/boot/cpucheck.c:#ifdef _SETUP
> 
> which is already under arch/x86/boot/. arch/x86/boot/Makefile
> unconditionally sets -D_SETUP, so what/who are we guarding against?
> Looks like a guard that's ALWAYS true (and thus could be removed).

Looks like cpucheck.c was used somewhere else before and that guard was
for when it is being built in arch/x86/boot/...

Also, hpa says the override is because some 64-bit flags fail the 32-bit
compile:

https://lkml.kernel.org/r/56442061-7f55-878d-5b26-7cdd14e901d2@xxxxxxxxx

> Or, or... we don't redefine KBUILD_CFLAGS in arch/x86/boot/Makefile
> (or any Makefile other than the top level one), and simply filter out
> the flags we DONT want, a la:
> 
> drivers/firmware/efi/libstub/Makefile:
>  16 cflags-$(CONFIG_ARM64)    := $(subst -pg,,$(KBUILD_CFLAGS)) ...
> 
> ie, using Make's subst function to copy KBUILD_CFLAGS, filter out
> results, then use that for cflags-y.
> https://www.gnu.org/software/make/manual/html_node/Text-Functions.html

Hmm, definitely sounds like an interesting idea to try...

> I'm curious to know Masahiro's thoughts on this?  I can't help but
> shake the feeling that reassigning KBUILD_CFLAGS should be considered
> an anti-pattern and warned from checkpatch.pl.  For the reasons
> enumerated above AND in v1:
> https://lore.kernel.org/lkml/CAKwvOdmLSVH7EVGY1ExU1Fh_hvL=FUzhq-80snDfZ+QhCT2FOA@xxxxxxxxxxxxxx/
> (though there may be additional context from hpa answering
> https://lore.kernel.org/lkml/20180926090841.GC5745@xxxxxxx/).
> 
> Relying on the compiler's default/implicit C standard (which changed
> in gcc 5) for parts of the kernel but not others I feel like should be
> a big red flag.

I sure see your point. But then there's also the opposing argument where
having stuff leak from kernel proper into .../boot/ is simply breaking
the build.

But then we have headers including stuff from kernel proper so I guess
*that* last fact kinda wants us to not redefine KBUILD_CFLAGS ...

Oh boy.

> Shall I prototype up what such a change might look like (not
> reassigning KBUILD_CFLAGS in arch/x86/boot/Makefile)?  Maybe it's
> harder/uglier than I imagine?

Sounds to me like a good thing to try. If anything, we'll know more
whether it makes sense at all.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.