[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180322185524.GA78232@google.com>
Date: Thu, 22 Mar 2018 11:55:24 -0700
From: Matthias Kaehlcke <mka@...omium.org>
To: Dave Martin <Dave.Martin@....com>
Cc: Robin Murphy <robin.murphy@....com>,
Andrey Konovalov <andreyknvl@...gle.com>,
ard.biesheuvel@...aro.org, Marc Zyngier <marc.zyngier@....com>,
Catalin Marinas <catalin.marinas@....com>,
LKML <linux-kernel@...r.kernel.org>,
Kostya Serebryany <kcc@...gle.com>,
linux-arm-kernel@...ts.infradead.org,
Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: Clang build of arm64 kernel fails
El Thu, Mar 01, 2018 at 10:31:02AM +0000 Dave Martin ha dit:
> On Thu, Mar 01, 2018 at 09:45:24AM +0000, Robin Murphy wrote:
> > Hi Andrey,
> >
> > On 28/02/18 19:32, Andrey Konovalov wrote:
> > >Hi Marc!
> > >
> > >I've tried to pull in new upstream commits and the kernel build
> > >started failing for me with the following errors (see below).
> > >
> > >It seems that the reason is your commit "arm64: Add
> > >ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support". It seems that Clang
> > >doesn't like 32 bits registers being used in 64 bits build.
> >
> > I'd say this is really a bug in Clang. Architecturally, the register in
> > AArch64 state is still named "r0"; "x0"/"w0" are assembler operands which
> > additionally encode the size of the corresponding *access* to r0.
> >
> > I note that GCC's documentation on register variables[1] does just say "the
> > name of the register", which implies this code is not incorrect. Given that
> > Clang already likes to infer the operand size from the argument type in
> > actual inline asms, it seems funny that its register allocator should care
> > in this non-instruction context.
>
> +1
>
> rN is perfectly reasonable here and has always been supported by GCC for
> AArch64 AFAIK.
>
> (IMHO rN is preferable, because this separates the register allocation
> specification from how that register is used to encode the data type --
> GCC has no choice about the latter, but using "w"/"x" gives the
> misleading impression of control over this.)
>
> > >Would you mind sending a fix?
> >
> > That said, I guess it's a bug we might have to work around anyway. Oh well.
>
> It would be preferable to see evidence of the llvm community committing
> to fix this before we consider merging a bodge into Linux for it.
>
> Although this one issue is easy-ish to work around, we're on a slippery
> slope towards allowing the LLVM and GCC inline assemblers to diverge if
> we don't push back on worthless incompatibilities.
For the record, a LLVM bug was opened to add support for the rN names
in constraints: https://bugs.llvm.org/show_bug.cgi?id=36862 . I know
Manoj intends to submit a fix once the scope has been clarified.
I plan to send a kernel fix soon, unless someone beats me to it.
Matthias
Powered by blists - more mailing lists