There is inconsistency in ARM support and I'd like to gather some opinions on how to resolve it. Circulate this to ARM people near you.
At some point an inconsistency of following nature was introduced and then just grew. OpenSSL attempts to adapt to processor it's running on by detecting capabilities and using run-time switch between different code paths. The code probing capabilities is compiled and executed on all supported ARM architectures, ARMv4 through ARMv8. Original rationale was that one should be able to produce "universal" binary that can be executed on wide range of processors and deliver optimal performance on all of them. But at the same time assembly modules have #if __ARM_ARCH__>=X which effectively renders them not as universal as implied in capability probing code. This is the inconsistency. There are two ways to resolve it. 1. __ARM_ARCH__ is effectively controlled by compiler -march command line option, which naturally also controls compiler-generated outcome. In order to live up to original intention to produce "universal" binary, it would be appropriate to tell *compiler* to generate code for minimal architecture one wants to target, but tell *assembler* to accept instructions for maximum architecture one wants to target, e.g. -march=armv4 -Wa,-march=armv7-a. 2. Abandon the idea of producing true "universal" binary and limit capability detection to contemporary processor families, ARMv7/8 for the moment of this writing. And run pre-ARMv7 without capability detection (there is nothing to detect really). I suppose distro vendors would prefer 2nd option, because everything has to match anyway. ISV on the other hand might prefer 1st one, unless of course they target specific distros one by one rather than providing unified binaries that can be executed on multiple distros. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
