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
WARNING: multiple messages have this Message-ID (diff)
From: Matthias Kaehlcke <mka@chromium.org>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
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, 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: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-28 19:32 Clang build of arm64 kernel fails Andrey Konovalov
2018-02-28 19:32 ` Andrey Konovalov
2018-03-01 9:45 ` Robin Murphy
2018-03-01 9:45 ` Robin Murphy
2018-03-01 10:31 ` Dave Martin
2018-03-01 10:31 ` Dave Martin
2018-03-22 18:55 ` Matthias Kaehlcke [this message]
2018-03-22 18:55 ` Matthias Kaehlcke
2018-03-01 10:47 ` Marc Zyngier
2018-03-01 10:47 ` Marc Zyngier
2018-03-01 12:31 ` Andrey Konovalov
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.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.