Re: [PATCH] x86/boot: define CC_HAVE_ASM_GOTO

["H. Peter Anvin" <hpa@zytor.com>]

On 09/26/18 02:08, Borislav Petkov wrote:
> On Tue, Sep 25, 2018 at 02:13:16PM -0700, Nick Desaulniers wrote:
>> Orthogonally, do you know *why* this Makefile overwrites
>> KBUILD_CFLAGS?  We take great care to set various compiler flags in
>> the top level Makefile, so to reset them lower in the tree seems
>> troublesome on first glance.  Take for instance the fact that GCC
>> changed the default C standard from gnu89 to gnu11 in GCC 5.  So a
>> kernel dev with gcc 5+ is now building a kernel with some translation
>> units built as gnu89, and some as gnu11.
> 
> Right, so I'd defer to hpa for a definitive answer here but AFAICT, the
> reasoning is that because this is the special relocatable compressed
> kernel and as such, it is redefining build flags completely so that
> nothing leaks from kernel proper.
> 
> Which is funny because what happens is, that something *does* leak,
> and what you're trying to fix is one incarnation. Because we do use
> facilities from include/linux/. And looking at your error:
> 
> #warning "Compiler lacks ASM_GOTO support. Add -D __BPF_TRACING__ to your compiler arguments"
> 
> I don't think it does matter to the compressed kernel whether the
> compiler has asm goto or not.
> 
> And looking at arch/x86/boot/Makefile, it does:
> 
> KBUILD_CFLAGS   := $(REALMODE_CFLAGS) -D_SETUP
> 
> and that _SETUP guard is kinda used to separate that early boot code
> from kernel proper.
> 
> And I wonder if adding such guard to arch/x86/boot/compressed/Makefile
> and then protect the asm goto check in arch/x86/include/asm/cpufeature.h
> with it, would be more in line with how this whole machinery should
> work...
> 

It overrides CFLAGS because it is by necessity a 32-bit compile (16
bits, really, but that's done at the assembly level only.)  Some 64-bit
flags cause the 32-bit compile to error out.

	-hpa