From: mka@chromium•org (Matthias Kaehlcke)
To: linux-arm-kernel@lists•infradead.org
Subject: Clang build of arm64 kernel fails
Date: Thu, 22 Mar 2018 11:55:24 -0700 [thread overview]
Message-ID: <20180322185524.GA78232@google.com> (raw)
In-Reply-To: <20180301103100.GE32331@e103592.cambridge.arm.com>
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
next prev parent reply other threads:[~2018-03-22 18:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-28 19:32 Clang build of arm64 kernel fails Andrey Konovalov
2018-03-01 9:45 ` Robin Murphy
2018-03-01 10:31 ` Dave Martin
2018-03-22 18:55 ` Matthias Kaehlcke [this message]
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=20180322185524.GA78232@google.com \
--to=mka@chromium$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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