On 31 October 2014 18:12, Andy Polyakov <ap...@openssl.org> wrote: >> Anyway. As nobody seems to be objecting, it sounds like we are going for >> combination of both alternatives? I.e. those who specify specific -march >> lower than armv7 would be excused from capability detection and run-time >> switch, and those who additionally specify "better" -Wa and >> corresponding -D, would be able to build universal binaries of their >> liking. I'll give it some extra time for others to ponder and make a >> suggestion. It would be easier to discuss details then. > > Attached is suggestion on how to implement this. [I thought it would > take more tweaking]. I scrapped -Wa, as -D__ARM_MAX_ARCH__=N was > sufficient. Most of what needs to be said is said in commentary in > ./Configure (see beginning of patch). But this is "most". There are > couple of controversial points that are likely to need clarification. > The reason for why I didn't add '.arch armv7-a' in all #if > __ARM_MAX_ARCH>=7 sections is because '.fpu neon' appears to be > sufficient to compile the code, while *not* having '.arch armv7-a' > (where possible) would allow to catch attempts to use new instructions > in places where it's inappropriate when building universal. Second > controversial point is that ARMv8 crypto is compiled even with > __ARM_MAX_ARCH__>=7. This is done so to say to popularize ARMv8 crypto > among those who won't read commentary section in Configure, as well as > among Android [and in future iOS] people. [Well, -D__ARM_MAX_ARCH__=8 > would work there too, but there are even more likely to miss the memo]. >
I had a go with your patch, but I think there are still problems with the missing .arch armv7-a For instance, when building using a compiler whose default is armv5t and passing __ARM_MAX_ARCH__=8, I get the following build error arm-linux-gnueabi-gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D__ARM_MAX_ARCH__=8 -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -c -c -o aesv8-armx.o aesv8-armx.S aesv8-armx.S: Assembler messages: aesv8-armx.S:574: Error: selected processor does not support ARM mode `rev r8,r8' aesv8-armx.S:581: Error: selected processor does not support ARM mode `rev r10,r10' aesv8-armx.S:584: Error: selected processor does not support ARM mode `rev r12,r8' aesv8-armx.S:642: Error: selected processor does not support ARM mode `rev r9,r9' aesv8-armx.S:648: Error: selected processor does not support ARM mode `rev r10,r10' aesv8-armx.S:653: Error: selected processor does not support ARM mode `rev r12,r8' make[2]: *** [aesv8-armx.o] Error 1 I think leaving out the .arch armv7-a is more trouble than it's worth: there are no ARMv6 CPUs that support NEON anyway. Other than that, I think this approach is fine -- Ard. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
