From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] arm64: alternatives: Work around NOP generation with broken assembler
Date: Mon, 5 Dec 2016 10:05:46 +0000 [thread overview]
Message-ID: <20161205100545.GA14058@arm.com> (raw)
In-Reply-To: <20161203140538.23525-3-marc.zyngier@arm.com>
On Sat, Dec 03, 2016 at 02:05:38PM +0000, Marc Zyngier wrote:
> When compiling a .inst directive in an alternative clause with
> a rather old version of gas (circa 2.24), and when used with
> the alternative_else_nop_endif feature, the compilation fails
> with a rather cryptic message such as:
>
> arch/arm64/lib/clear_user.S:33: Error: bad or irreducible absolute expression
>
> which is caused by the bug described in eb7c11ee3c5c ("arm64:
> alternative: Work around .inst assembler bugs").
>
> This effectively prevents the use of the "nops" macro, which
> requires the number of instruction as a parameter (the assembler
> is confused and unable to compute the difference between two labels).
>
> As an alternative(!), use the .fill directive to output the number
> of required NOPs (.fill has the good idea to output the fill pattern
> in the endianness of the instruction stream).
Are you sure about that? The gas docs say:
`The contents of each repeat bytes is taken from an 8-byte number. The
highest order 4 bytes are zero. The lowest order 4 bytes are value rendered
in the byte-order of an integer on the computer as is assembling for.'
and I'd expect "integer" to refer to data values, rather than instructions.
>
> Fixes: 792d47379f4d ("arm64: alternative: add auto-nop infrastructure")
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/include/asm/alternative.h | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
> index 39feb85..39f8c98 100644
> --- a/arch/arm64/include/asm/alternative.h
> +++ b/arch/arm64/include/asm/alternative.h
> @@ -159,9 +159,19 @@ void apply_alternatives(void *start, size_t length);
> * of NOPs. The number of NOPs is chosen automatically to match the
> * previous case.
> */
> +
> +#define NOP_INST 0xd503201f
If we define this, let's put it in insn.h or something. It could even be
used in the vdso linker script, which open codes this constant.
> +
> .macro alternative_else_nop_endif
> alternative_else
> - nops (662b-661b) / AARCH64_INSN_SIZE
> + /*
> + * The same assembler bug strikes again here if the first half
> + * of the alternative sequence contains a .inst, leading to a
> + * bizarre error message. Fortulately, .fill replaces the
Fortunately
> + * "nops" macro by inserting padding with the target machine
> + * endianness.
> + */
> + .fill (662b-661b) / AARCH64_INSN_SIZE, AARCH64_INSN_SIZE, NOP_INST
Assuming we can get .fill to do the right thing, we should probably use
it in __nops rather than open-coding it here. Or is the issue that we're
unable to pass (662b-661b) / AARCH64_INSN_SIZE to any macro?
Will
next prev parent reply other threads:[~2016-12-05 10:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-03 14:05 [PATCH 0/2] Fix fallouts from asm/opcodes.h removal Marc Zyngier
2016-12-03 14:05 ` [PATCH 1/2] arm64: Remove reference to asm/opcodes.h Marc Zyngier
2016-12-03 14:05 ` [PATCH 2/2] arm64: alternatives: Work around NOP generation with broken assembler Marc Zyngier
2016-12-05 10:05 ` Will Deacon [this message]
2016-12-05 10:58 ` Marc Zyngier
2016-12-05 11:54 ` Marc Zyngier
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=20161205100545.GA14058@arm.com \
--to=will.deacon@arm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).