On 3 November 2014 15:17, 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. 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... >
I do agree. Perhaps the AES v8 is just not a good example, because it only runs on v8 and higher anyway. But in case of mixed modules, we should indeed be very careful not to emit unsupported instructions. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
