[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0dda3996-a4f3-33f8-ef4f-935943f132b4@arm.com>
Date: Tue, 21 Aug 2018 18:25:18 +0100
From: Robin Murphy <robin.murphy@....com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
LKML <linux-kernel@...r.kernel.org>,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm64/crypto: remove non-standard notation
On 21/08/18 18:00, Ard Biesheuvel wrote:
> On 21 August 2018 at 18:50, Nick Desaulniers <ndesaulniers@...gle.com> wrote:
>> On Tue, Aug 21, 2018 at 5:23 AM Ard Biesheuvel
>> <ard.biesheuvel@...aro.org> wrote:
>>>
>>> Hi Nick,
>>>
>>> On 21 August 2018 at 00:40, Nick Desaulniers <ndesaulniers@...gle.com> wrote:
>>>> It seems that:
>>>> ldr q8, =0x30000000200000001
>>>>
>>>> is a GNU as convience notation for:
>>>> ldr q8, .Lconstant
>>>> .Lconstant
>>>> .word 0x00000001
>>>> .word 0x00000002
>>>> .word 0x00000003
>>>> .word 0x00000000
>>>>
>>>> based on this comment in binutils' source [0]. I've asked for this
>>>> non-standard convience notation to be added to other assemblers [1], but
>>>> until then, we can remove it and get equivalent disassembly:
>>>>
>>>
>>> What do you mean by 'non-standard convenience notation'? Which asm
>>> 'standard' does Clang actually claim to implement?
>>
>> Well, for assembly 'standard' is a bit nebulous. But it's frustrating
>> when you can't find what the `=0x...` notation means in either the ARM
>> or GNU as manuals. The source of truth happened to be a comment in
>> the source [0] that explained that this was a "programmer friendly
>> notation." Sure, if you can find it.
>>
>
> Well, it is documented in the ARM manuals as the 'ldr pseudo
> instruction' for 32-bit ARM, and originally, it would only emit a
> literal if the value could not be loaded using a ordinary mov.
FWIW It's certainly well-documented by common A64 assemblers too:
http://infocenter.arm.com/help/topic/com.arm.doc.100069_0610_01_en/dom1395139540926.html
https://sourceware.org/binutils/docs/as/AArch64-Opcodes.html#AArch64-Opcodes
> For AArch64, I don't think that occurs any longer, i.e., a ldr is
> always emitted as an ldr. However, it is used widely in the ARM code
> (although not as much in arch/arm64) for loading compile time
> constants and even symbol addresses into general purpose registers.
> The FP variant may actually be a GNU invention, but given that there
> is no standard to begin with, playing the 'GNU is non-standard' card
> again is just a bit annoying.
I note that GAS just says "register" rather than explicitly calling out
GPRs as armasm does, so in some ways it's not even all that unexpected
that FP registers also work there, even if it is a bit funky.
Robin.
Powered by blists - more mailing lists