Set static armcaps based on __ARM_FEATURE_CRYPTO.

Originally we had some confusion around whether the features could be
toggled individually or not. Per the ARM C Language Extensions doc[1],
__ARM_FEATURE_CRYPTO implies the "crypto extension" which encompasses
all of them. The runtime CPUID equivalent can report the features
individually, but it seems no one separates them in practice, for now.
(If they ever do, probably there'll be a new set of #defines.)

[1] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf

Change-Id: I12915dfc308f58fb005286db75e50d8328eeb3ea
Reviewed-on: https://boringssl-review.googlesource.com/16991
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>

BUILDING.md

@@ -125,16 +125,18 @@ ARM, unlike Intel, does not have an instruction that allows applications to
 discover the capabilities of the processor. Instead, the capability information
 has to be provided by the operating system somehow.
 
-BoringSSL will try to use `getauxval` to discover the capabilities and, failing
-that, will probe for NEON support by executing a NEON instruction and handling
-any illegal-instruction signal. But some environments don't support that sort
-of thing and, for them, it's possible to configure the CPU capabilities
-at compile time.
-
-If you define `OPENSSL_STATIC_ARMCAP` then you can define any of the following
-to enabling the corresponding ARM feature.
-
-  * `OPENSSL_STATIC_ARMCAP_NEON` or `__ARM_NEON__` (note that the latter is set by compilers when NEON support is enabled).
+By default, on Linux-based systems, BoringSSL will try to use `getauxval` and
+`/proc` to discover the capabilities. But some environments don't support that
+sort of thing and, for them, it's possible to configure the CPU capabilities at
+compile time.
+
+On iOS or builds which define `OPENSSL_STATIC_ARMCAP`, features will be
+determined based on the `__ARM_NEON__` and `__ARM_FEATURE_CRYPTO` preprocessor
+symbols reported by the compiler. These values are usually controlled by the
+`-march` flag. You can also define any of the following to enable the
+corresponding ARM feature.
+
+  * `OPENSSL_STATIC_ARMCAP_NEON`
   * `OPENSSL_STATIC_ARMCAP_AES`
   * `OPENSSL_STATIC_ARMCAP_SHA1`
   * `OPENSSL_STATIC_ARMCAP_SHA256`

crypto/crypto.c

@@ -73,16 +73,16 @@ uint32_t OPENSSL_armcap_P =
 #if defined(OPENSSL_STATIC_ARMCAP_NEON) || defined(__ARM_NEON__)
     ARMV7_NEON |
 #endif
-#if defined(OPENSSL_STATIC_ARMCAP_AES)
+#if defined(OPENSSL_STATIC_ARMCAP_AES) || defined(__ARM_FEATURE_CRYPTO)
     ARMV8_AES |
 #endif
-#if defined(OPENSSL_STATIC_ARMCAP_SHA1)
+#if defined(OPENSSL_STATIC_ARMCAP_SHA1) || defined(__ARM_FEATURE_CRYPTO)
     ARMV8_SHA1 |
 #endif
-#if defined(OPENSSL_STATIC_ARMCAP_SHA256)
+#if defined(OPENSSL_STATIC_ARMCAP_SHA256) || defined(__ARM_FEATURE_CRYPTO)
     ARMV8_SHA256 |
 #endif
-#if defined(OPENSSL_STATIC_ARMCAP_PMULL)
+#if defined(OPENSSL_STATIC_ARMCAP_PMULL) || defined(__ARM_FEATURE_CRYPTO)
     ARMV8_PMULL |
 #endif
     0;

include/openssl/cpu.h

@@ -156,7 +156,7 @@ static inline int CRYPTO_is_NEON_capable(void) {
 }
 
 static inline int CRYPTO_is_ARMv8_AES_capable(void) {
-#if defined(OPENSSL_STATIC_ARMCAP_AES)
+#if defined(OPENSSL_STATIC_ARMCAP_AES) || defined(__ARM_FEATURE_CRYPTO)
   return 1;
 #else
   return 0;
@@ -164,7 +164,7 @@ static inline int CRYPTO_is_ARMv8_AES_capable(void) {
 }
 
 static inline int CRYPTO_is_ARMv8_PMULL_capable(void) {
-#if defined(OPENSSL_STATIC_ARMCAP_PMULL)
+#if defined(OPENSSL_STATIC_ARMCAP_PMULL) || defined(__ARM_FEATURE_CRYPTO)
   return 1;
 #else
   return 0;