Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20180907202618.258569-1-ndesaulniers@google.com>
 <CAKwvOdn4BcKUjGnGgFfbGxbwvSh9mYLT1gJ_ozDHua1LcjJ1rw@mail.gmail.com>
 <20180925190829.GC15464@zn.tnic> <CAKwvOdmaUMmLAv-529A0ShW7et3Jnnmc4Agjody+VReN5feTeg@mail.gmail.com>
In-Reply-To: <CAKwvOdmaUMmLAv-529A0ShW7et3Jnnmc4Agjody+VReN5feTeg@mail.gmail.com>
From:   Nick Desaulniers <ndesaulniers@google.com>
Date:   Tue, 25 Sep 2018 14:13:16 -0700
Message-ID: <CAKwvOdmLSVH7EVGY1ExU1Fh_hvL=FUzhq-80snDfZ+QhCT2FOA@mail.gmail.com>
Subject: Re: [PATCH] x86/boot: define CC_HAVE_ASM_GOTO
To:     bp@suse.de
Cc:     Thomas Gleixner <tglx@linutronix.de>, mingo@redhat.com,
        hpa@zytor.com, x86@kernel.org,
        "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
        Masahiro Yamada <yamada.masahiro@socionext.com>,
        Matthias Kaehlcke <mka@chromium.org>,
        Kees Cook <keescook@chromium.org>,
        Cao jin <caoj.fnst@cn.fujitsu.com>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Sep 25, 2018 at 2:08 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Tue, Sep 25, 2018 at 12:08 PM Borislav Petkov <bp@suse.de> wrote:
> >
> > On Tue, Sep 25, 2018 at 11:41:19AM -0700, Nick Desaulniers wrote:
> > > bumping for review.
> > >
> > > On Fri, Sep 7, 2018 at 1:26 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
> > > >
> > > > Since this file steamrolls KBUILD_CFLAGS, we have to redefine these
> > > > symbols.

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.

> >
> > Why do we have to redefine these symbols?
> >
> > I don't see arch/x86/boot/ using asm_volatile_goto() and
> > CC_HAVE_ASM_GOTO anywhere.
>
> They may not explicitly invoke asm_volatile_goto(), but many
> translation units under arch/x86/boot/compressed/ share this include
> path, triggering this warning:
>
> In file included from arch/x86/boot/compressed/misc.h:20:
> In file included from ./include/linux/elf.h:5:
> In file included from ./arch/x86/include/asm/elf.h:8:
> In file included from ./include/linux/thread_info.h:38:
> In file included from ./arch/x86/include/asm/thread_info.h:53:
> ./arch/x86/include/asm/cpufeature.h:150:2: warning: "Compiler lacks
> ASM_GOTO support. Add -D __BPF_TRACING__ to your compiler arguments"
> [-W#warnings]
> #warning "Compiler lacks ASM_GOTO support. Add -D __BPF_TRACING__ to
> your compiler arguments"
>  ^
>
> specifically 6 instances from:
> In file included from arch/x86/boot/compressed/early_serial_console.c:1:
> In file included from arch/x86/boot/compressed/cmdline.c:2:
> In file included from arch/x86/boot/compressed/error.c:7:
> In file included from arch/x86/boot/compressed/kaslr.c:29:
> In file included from arch/x86/boot/compressed/kaslr_64.c:22:
> In file included from arch/x86/boot/compressed/misc.c:15:
>
> Note that the check in arch/x86/include/asm/cpufeature.h has the check:
>
> 143 #if defined(__clang__) && !defined(CC_HAVE_ASM_GOTO)
>
> so this is hidden from GCC.  I can include this information in the
> commit message for a v2 if you'd like?
>
> >
> > > > This will prevent warnings in source files in this directory
> > > > when Clang supports asm goto.
> >
> > This statement I can't grok either. Maybe I'm slow or maybe I need more
> > background info...
>
> We're in the process of adding asm goto support to Clang.  I'm helping
> test by working through compiling the Linux kernel with Clang for
> x86_64.  The patch set still has some kinks we're working out, but
> having this fix in place will make for smoother sailing once we're
> good to go, and we would appreciate having it.
>
> --
> Thanks,
> ~Nick Desaulniers


-- 
Thanks,
~Nick Desaulniers