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
