>>> 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. Consider case similar to yours, i.e. -march=armv5t -D__ARM_MAX_ARCH__=8. Then consider module that contains two code paths, IALU that will execute on ARMv5 processor and NEON that will execute on ARMv7. There are non-NEON[!] instructions I can't use in IALU code path (rev is one of them) and I want assembler to tell me that. As opposite to finding out from problem report after release. I mean if '.arch armv7-a' is specified in code and I use such non-NEON instruction *without* correct #if __ARM_ARCH__>=X, I won't notice it and code will crash on ARMv5 processor in the field. Or in other words, question was *when* do we want to notice that kind of mistakes. 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... Thanks for feedback. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
