Re: libcrypto: fix assembly for clang
On Wed, Jan 4, 2017 at 5:12 AM, Mark Kettenis wrote: > > Date: Wed, 4 Jan 2017 11:04:43 +0100 > > From: Patrick Wildt > > > > On Tue, Jan 03, 2017 at 02:16:25PM -0500, Ted Unangst wrote: > > > Patrick Wildt wrote: > > > > > > > > Maybe they want to support older binutils that do not support the > unified syntax? > > > > What's our policy there? > > > > > > OpenBSD is just about the oldest binutils around. I wouldn't worry > about > > > anything older than what we have in base. > > > > Considering that, I'm going to ask for OKs then. > > > > ok? > > ok kettenis@, but lets give the LibreSSL people a chance to raise any > portability concerns as they might have a better idea about LibreSSL > portable deployment on ARM. > > ok bcook@ - we don't even enable assembly on ARM in portable. Happy if someone wants to help change that.
Re: libcrypto: fix assembly for clang
> Date: Wed, 4 Jan 2017 11:04:43 +0100 > From: Patrick Wildt > > On Tue, Jan 03, 2017 at 02:16:25PM -0500, Ted Unangst wrote: > > Patrick Wildt wrote: > > > > > > Maybe they want to support older binutils that do not support the unified > > > syntax? > > > What's our policy there? > > > > OpenBSD is just about the oldest binutils around. I wouldn't worry about > > anything older than what we have in base. > > Considering that, I'm going to ask for OKs then. > > ok? ok kettenis@, but lets give the LibreSSL people a chance to raise any portability concerns as they might have a better idea about LibreSSL portable deployment on ARM.
Re: libcrypto: fix assembly for clang
On Tue, Jan 03, 2017 at 02:16:25PM -0500, Ted Unangst wrote: > Patrick Wildt wrote: > > > > Maybe they want to support older binutils that do not support the unified > > syntax? > > What's our policy there? > > OpenBSD is just about the oldest binutils around. I wouldn't worry about > anything older than what we have in base. Considering that, I'm going to ask for OKs then. ok?
Re: libcrypto: fix assembly for clang
Patrick Wildt wrote: > > Maybe they want to support older binutils that do not support the unified > syntax? > What's our policy there? OpenBSD is just about the oldest binutils around. I wouldn't worry about anything older than what we have in base.
libcrypto: fix assembly for clang
Hi, clang complains about the ARM assembly, since it expects the conditional branch instructions to state the condition (in this case pl/ne) after the "b" for branch. We also need to state that we're using the unified syntax, so that binutils 2.17 likes it as well. OpenSSL fixed that issue in another way: .text #if defined(__thumb2__) || defined(__clang__) .syntax unified #endif #if defined(__thumb2__) .thumb #else .code 32 #endif #ifdef __clang__ #define ldrplb ldrbpl #define ldrneb ldrbne #endif Maybe they want to support older binutils that do not support the unified syntax? What's our policy there? Comments? Patrick diff --git a/lib/libcrypto/modes/asm/ghash-armv4.pl b/lib/libcrypto/modes/asm/ghash-armv4.pl index d91586ee292..4f8372d8974 100644 --- a/lib/libcrypto/modes/asm/ghash-armv4.pl +++ b/lib/libcrypto/modes/asm/ghash-armv4.pl @@ -110,6 +110,7 @@ $code=<<___; #include "arm_arch.h" .text +.syntaxunified .code 32 .type rem_4bit,%object @@ -182,7 +183,7 @@ gcm_ghash_4bit: eor $Zlh,$Zlh,$Zhl,lsl#28 ldrh$Tll,[sp,$nlo] @ rem_4bit[rem] eor $Zhl,$Thl,$Zhl,lsr#4 - ldrplb $nlo,[$inp,$cnt] + ldrbpl $nlo,[$inp,$cnt] eor $Zhl,$Zhl,$Zhh,lsl#28 eor $Zhh,$Thh,$Zhh,lsr#4 @@ -192,7 +193,7 @@ gcm_ghash_4bit: add $nhi,$nhi,$nhi ldmia $Thh,{$Tll-$Thh}@ load Htbl[nhi] eor $Zll,$Tll,$Zll,lsr#4 - ldrplb $Tll,[$Xi,$cnt] + ldrbpl $Tll,[$Xi,$cnt] eor $Zll,$Zll,$Zlh,lsl#28 eor $Zlh,$Tlh,$Zlh,lsr#4 ldrh$Tlh,[sp,$nhi] @@ -210,7 +211,7 @@ gcm_ghash_4bit: add $inp,$inp,#16 mov $nhi,$Zll ___ - &Zsmash("cmp\t$inp,$len","ldrneb\t$nlo,[$inp,#15]"); + &Zsmash("cmp\t$inp,$len","ldrbne\t$nlo,[$inp,#15]"); $code.=<<___; bne .Louter @@ -268,7 +269,7 @@ gcm_gmult_4bit: eor $Zlh,$Zlh,$Zhl,lsl#28 ldrh$Tll,[$rem_4bit,$nlo] @ rem_4bit[rem] eor $Zhl,$Thl,$Zhl,lsr#4 - ldrplb $nlo,[$Xi,$cnt] + ldrbpl $nlo,[$Xi,$cnt] eor $Zhl,$Zhl,$Zhh,lsl#28 eor $Zhh,$Thh,$Zhh,lsr#4