On 3 November 2014 18:36, Andy Polyakov <[email protected]> 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. >> >> But it's not about NEON at all. ... But I >> understand the concern and will give it another consideration. .arch >> seems to be positional in sense that it fails non-matching instructions >> above it... > > Attached is version that attempts to exploit the fact that .arch > directive appears to be positional and add .arch armv7-a everywhere, > just not in the beginnings of mixed-code files. For this I had to > reorder code paths in armv4cpuid and armv4-gfm modules. >
I have tested this with the stock Ubuntu ARM EABI soft float toolchain (which targets for armv5t non-Thumb), and added the max arch == 8, and it builds fine and produces a binary that will use NEON or crypto instructions if the cpu's capabilities allow it. (Tested on 32-bit and 64-bit ARM systems) -- Ard. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
