From: Dave Martin <Dave.Martin@arm.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
ard.biesheuvel@linaro.org, Marc Zyngier <marc.zyngier@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Kostya Serebryany <kcc@google.com>,
linux-arm-kernel@lists.infradead.org,
Dmitry Vyukov <dvyukov@google.com>
Subject: Re: Clang build of arm64 kernel fails
Date: Thu, 1 Mar 2018 10:31:02 +0000 [thread overview]
Message-ID: <20180301103100.GE32331@e103592.cambridge.arm.com> (raw)
In-Reply-To: <d601e0ca-dd91-3dd4-c610-dd2ae49aa1b6@arm.com>
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.
Cheers
---Dave
next prev parent reply other threads:[~2018-03-01 10:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-28 19:32 Andrey Konovalov
2018-03-01 9:45 ` Robin Murphy
2018-03-01 10:31 ` Dave Martin [this message]
2018-03-22 18:55 ` Matthias Kaehlcke
2018-03-01 10:47 ` Marc Zyngier
2018-03-01 12:31 ` Andrey Konovalov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180301103100.GE32331@e103592.cambridge.arm.com \
--to=dave.martin@arm.com \
--cc=andreyknvl@google.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=dvyukov@google.com \
--cc=kcc@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=robin.murphy@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®