Re: [openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)
What if relocation's were not resolved correctly and run-time switch doesn't really work as intended. It's possible to confirm this indirectly by comparing results for 'apps/openssl speed sha' and 'env OPENSSL_armcap=0 apps/openssl speed sha'. Can you do that? I have done the performance checking as you have pointed out.There is a performance difference, So run time switch is working as expected. On Thu, Jun 18, 2015 at 6:50 PM, Andy Polyakov ap...@openssl.org wrote: It is compiling successfully and all openssl test are passing for ILP32 abi. There are remaining questions. The fact that tests pass is definitely good sign, but there still is an open and burning question. What if relocations were not resolved correctly and run-time switch doesn't really work as intended. It's possible to confirm this indirectly by comparing results for 'apps/openssl speed sha' and 'env OPENSSL_armcap=0 apps/openssl speed sha'. Can you do that? Development branch has more ARMv8 code. Can you test that too? And last question is not really a question. All this ought to mean that you have put together all those not-yet-upstreamed bits together, i.e. glibc, multilib, kernel patches, huh? For public reference I want once again to point out that additional ABI for AArch64 is work in very progress, and so far the only way to compile 32-bit code and target ARMv8 was to adhere to usual 32-bit ARM support (which does utilize ARMv8 crypto extensions), and that is currently the supported way, for good or bad. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)
It is compiling successfully and all openssl test are passing for ILP32
abi.
Thanks.
On Thu, Jun 18, 2015 at 4:22 PM, Andy Polyakov ap...@openssl.org wrote:
I am compiling using the linaro aarch64 compiler for ILP32 ABI.
*linux-armv4 *compilation
with option -march =armv8_a giving lots of compilation errors as
compiler does not
supports mnemonics.
This is because toolchain referred to in one of previous messages is
only capable of generating/compiling AArch64 code. linux-armv4 is
equipped with AArch32 assembly and toolchain in question is indeed not
capable of compiling it. But it doesn't mean that if you compile
linux-armv4 target with right compiler you won't be able to run
resulting binary code on AArch64 system. This actually works and worked
from day one. Unlike abi=ilp32 that is (which is not actually
upstream-ed yet according https://wiki.linaro.org/Platform/arm64-ilp32).
Well, as for works from day one, you are likely to have to add 32-bit
libc, but on Debian [or derivative] it's straightforward dpkg
--add-architecture. Well, there also might be *processors* that don't
support AArch32 (ARM specification allows it), but all those readily
available now are all perfectly capable of executing linux-armv4
targets. And when it comes to ARMv8 crypto extensions, they would
deliver same performance as 64-bit code, so you don't loose anything.
(Not to mention that binary can be universal and make best of any
particular processor it executed on.)
So I have tried to compile with new configuration
for ilp32
with aarch64_asm.
linux-armilp32,gcc: -O3 -mabi=ilp32 -Wall::-D_REENTRANT::-ldl:
SIXTY_FOUR_BIT RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:
${aarch64_asm}::dlfcn:linux-shared:-fPIC:-mabi=ilp32:
.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
In compilation with this configuration getting error* cannot represent
BFD_RELOC_64 relocation in this object file format *in sha1-armv8.s.
Obviously it would require some adjustments, because mabi=ilp32 was not
considered when it was written. It might be sufficient to replace .quad
with .long, but there is no way for me to tell for reasons discussed in
the beginning. So that if there is some serious interest, then you have
to explain yourself better than providing reference to
releases.linaro.org.
After having a look at available documentation, attached patch is likely
to be sufficient to compile with -mabi=ilp32. But once again, I have no
way to actually verify it and therefore no promises can be provided.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)
It is compiling successfully and all openssl test are passing for ILP32 abi. There are remaining questions. The fact that tests pass is definitely good sign, but there still is an open and burning question. What if relocations were not resolved correctly and run-time switch doesn't really work as intended. It's possible to confirm this indirectly by comparing results for 'apps/openssl speed sha' and 'env OPENSSL_armcap=0 apps/openssl speed sha'. Can you do that? Development branch has more ARMv8 code. Can you test that too? And last question is not really a question. All this ought to mean that you have put together all those not-yet-upstreamed bits together, i.e. glibc, multilib, kernel patches, huh? For public reference I want once again to point out that additional ABI for AArch64 is work in very progress, and so far the only way to compile 32-bit code and target ARMv8 was to adhere to usual 32-bit ARM support (which does utilize ARMv8 crypto extensions), and that is currently the supported way, for good or bad. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)
I am compiling using the linaro aarch64 compiler for ILP32 ABI.
*linux-armv4 *compilation
with option -march =armv8_a giving lots of compilation errors as
compiler does not
supports mnemonics.
This is because toolchain referred to in one of previous messages is
only capable of generating/compiling AArch64 code. linux-armv4 is
equipped with AArch32 assembly and toolchain in question is indeed not
capable of compiling it. But it doesn't mean that if you compile
linux-armv4 target with right compiler you won't be able to run
resulting binary code on AArch64 system. This actually works and worked
from day one. Unlike abi=ilp32 that is (which is not actually
upstream-ed yet according https://wiki.linaro.org/Platform/arm64-ilp32).
Well, as for works from day one, you are likely to have to add 32-bit
libc, but on Debian [or derivative] it's straightforward dpkg
--add-architecture. Well, there also might be *processors* that don't
support AArch32 (ARM specification allows it), but all those readily
available now are all perfectly capable of executing linux-armv4
targets. And when it comes to ARMv8 crypto extensions, they would
deliver same performance as 64-bit code, so you don't loose anything.
(Not to mention that binary can be universal and make best of any
particular processor it executed on.)
So I have tried to compile with new configuration
for ilp32
with aarch64_asm.
linux-armilp32,gcc: -O3 -mabi=ilp32 -Wall::-D_REENTRANT::-ldl:
SIXTY_FOUR_BIT RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:
${aarch64_asm}::dlfcn:linux-shared:-fPIC:-mabi=ilp32:
.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
In compilation with this configuration getting error* cannot represent
BFD_RELOC_64 relocation in this object file format *in sha1-armv8.s.
Obviously it would require some adjustments, because mabi=ilp32 was not
considered when it was written. It might be sufficient to replace .quad
with .long, but there is no way for me to tell for reasons discussed in
the beginning. So that if there is some serious interest, then you have
to explain yourself better than providing reference to releases.linaro.org.
After having a look at available documentation, attached patch is likely
to be sufficient to compile with -mabi=ilp32. But once again, I have no
way to actually verify it and therefore no promises can be provided.
diff --git a/crypto/sha/asm/sha1-armv8.pl b/crypto/sha/asm/sha1-armv8.pl
index a8c08c2..5ef9dc2 100644
--- a/crypto/sha/asm/sha1-armv8.pl
+++ b/crypto/sha/asm/sha1-armv8.pl
@@ -171,7 +171,11 @@ $code.=___;
.type sha1_block_data_order,%function
.align 6
sha1_block_data_order:
+#ifdef __ILP32__
+ ldrsw x16,.LOPENSSL_armcap_P
+#else
ldr x16,.LOPENSSL_armcap_P
+#endif
adr x17,.LOPENSSL_armcap_P
add x16,x16,x17
ldr w16,[x16]
@@ -309,7 +313,11 @@ $code.=___;
.long 0x8f1bbcdc,0x8f1bbcdc,0x8f1bbcdc,0x8f1bbcdc //K_40_59
.long 0xca62c1d6,0xca62c1d6,0xca62c1d6,0xca62c1d6 //K_60_79
.LOPENSSL_armcap_P:
+#ifdef __ILP32__
+.long OPENSSL_armcap_P-.
+#else
.quad OPENSSL_armcap_P-.
+#endif
.asciz SHA1 block transform for ARMv8, CRYPTOGAMS by appro\@openssl.org
.align 2
.comm OPENSSL_armcap_P,4,4
diff --git a/crypto/sha/asm/sha512-armv8.pl b/crypto/sha/asm/sha512-armv8.pl
index d009f3f..7d69f0f 100644
--- a/crypto/sha/asm/sha512-armv8.pl
+++ b/crypto/sha/asm/sha512-armv8.pl
@@ -169,7 +169,11 @@ $code.=___;
$func:
___
$code.=___ if ($SZ==4);
+#ifdef __ILP32__
+ ldrsw x16,.LOPENSSL_armcap_P
+#else
ldr x16,.LOPENSSL_armcap_P
+#endif
adr x17,.LOPENSSL_armcap_P
add x16,x16,x17
ldr w16,[x16]
@@ -311,7 +315,11 @@ $code.=___;
.size .LK$BITS,.-.LK$BITS
.align 3
.LOPENSSL_armcap_P:
+#ifdef __ILP32__
+ .long OPENSSL_armcap_P-.
+#else
.quad OPENSSL_armcap_P-.
+#endif
.asciz SHA$BITS block transform for ARMv8, CRYPTOGAMS by appro\@openssl.org
.align 2
___
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)
First of all let's establish ground rule. In order for something to be
supported we ought to have access to platform, hardware is preferred,
emulator can be acceptable. It naturally also includes tool chain and
minimal ecosystem in form of working run-time. You refer to
releases.linaro.org, but is there mabi=ilp32 libc? I don't see one. I
have Debian jessie on 96board, but is there ilp32 libc available? I
don't see one. Is executable format in question widely supported by
kernel? Mine says exec format error... In other words to me ilp32 is
not viable option, which makes it impossible to support at this point.
I am compiling using the linaro aarch64 compiler for ILP32 ABI.
*linux-armv4 *compilation
with option -march =armv8_a giving lots of compilation errors as
compiler does not
supports mnemonics . So I have tried to compile with new configuration
for ilp32
with aarch64_asm.
linux-armilp32,gcc: -O3 -mabi=ilp32 -Wall::-D_REENTRANT::-ldl:
SIXTY_FOUR_BIT RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:
${aarch64_asm}::dlfcn:linux-shared:-fPIC:-mabi=ilp32:
.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
In compilation with this configuration getting error* cannot represent
BFD_RELOC_64 relocation in this object file format *in sha1-armv8.s.
Obviously it would require some adjustments, because mabi=ilp32 was not
considered when it was written. It might be sufficient to replace .quad
with .long, but there is no way for me to tell for reasons discussed in
the beginning. So that if there is some serious interest, then you have
to explain yourself better than providing reference to releases.linaro.org.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)
I am compiling using the linaro aarch64 compiler for ILP32 ABI. *linux-armv4
*compilation
with option -march =armv8_a giving lots of compilation errors as compiler
does not
supports mnemonics . So I have tried to compile with new configuration for
ilp32
with aarch64_asm.
linux-armilp32,gcc: -O3 -mabi=ilp32 -Wall::-D_REENTRANT::-ldl:
SIXTY_FOUR_BIT RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:
${aarch64_asm}::dlfcn:linux-shared:-fPIC:-mabi=ilp32:
.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
In compilation with this configuration getting error
* cannot represent BFD_RELOC_64 relocation in this object file
format *in sha1-armv8.s.
linaro compiler path (
http://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu
).
On Thu, Jun 11, 2015 at 1:52 PM, Andy Polyakov ap...@openssl.org wrote:
Hi,
Can we use armv8 assembly support provided in openssl-1.0.2a for
32 bit mode compilation.
It *is* used in 32-bit compilation as-is. aesv8-armx and ghashv8-armx
are included in armv4_asm, and sha1-armv4-large and sha256-armv4 modules
incorporate support for ARMv8 SHA instructions. But don't miss
commentary in Configure prior linux-armv4 line.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)
Hi, Can we use armv8 assembly support provided in openssl-1.0.2a for 32 bit mode compilation. It *is* used in 32-bit compilation as-is. aesv8-armx and ghashv8-armx are included in armv4_asm, and sha1-armv4-large and sha256-armv4 modules incorporate support for ARMv8 SHA instructions. But don't miss commentary in Configure prior linux-armv4 line. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)
Hi, Can we use armv8 assembly support provided in openssl-1.0.2a for 32 bit mode compilation. Regards, Gaurav ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
