Re: [PATCHv2] arm: crypto: Add optimized SHA-256/224

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 27 March 2015 at 11:42, Andy Polyakov <appro@openssl.org> wrote:
>>> Could you share the error log please?
>>
>> OK, I spotted one issue with this code:
>>
>> arch/arm/crypto/sha256-core.S: Assembler messages:
>> arch/arm/crypto/sha256-core.S:1847: Error: invalid constant (ffffefb0)
>> after fixup
>>
>> This is caused by the fact that, when building the integer-only code
>> for an older architecture, the conditional compilation produces a
>> slightly bigger preceding function, and the symbol K256 is out of
>> range for the adr instruction.
>>
>> @Jean-Christophe: is that the same problem that you hit?
>>
>> @Andy: I propose we do something similar as in the bsaes code:
>>
>> #ifdef __thumb__
>> #define adrl adr
>> #endif
>>
>> and replace the offending line with
>>
>> adrl r14,K256
>
> Sorry about delay. Yes, that would do. I did test all combinations, but
> all "my" combinations, i.e. without __KERNEL__ defined :-( And without
> __KERNEL__ there are few extra instructions in integer-only subroutine
> that "push" instruction in question code toward higher address, so that
> constant was ffffefc0, which can be encoded. Anyway, I've chosen to add
> that #define next to .thumb directive. See attached.
>
> Ard, you have mentioned that you've verified it on big-endian, but I've
> spotted little-endian dependency (see #ifndef __ARMEB__ in attached). I
> guess that it worked for you either because it was NEON that was tested
> (it does work as is) or __LINUX_ARM_ARCH__ was less than 7 (in which
> case it uses endian-neutral byte-by-byte data load). Can you confirm either?
>

I need to double check that, but my suspicion is that it was the latter.