|
|
@@ -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` |
|
|
|