diff options
| author | David Benjamin <davidben@google.com> | 2017-06-08 16:53:28 -0400 |
|---|---|---|
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | 2017-06-09 00:29:10 +0000 |
| commit | 3b33f3eb2deb05f20850393c18122b14955cfd42 (patch) | |
| tree | 3e128afb123d32dfa5361fe91517ec7f25535f8d /BUILDING.md | |
| parent | 619b323a5e82e79a01a44e5986640492892f86c6 (diff) | |
| download | boringssl-3b33f3eb2deb05f20850393c18122b14955cfd42.zip boringssl-3b33f3eb2deb05f20850393c18122b14955cfd42.tar.gz boringssl-3b33f3eb2deb05f20850393c18122b14955cfd42.tar.bz2 | |
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>
Diffstat (limited to 'BUILDING.md')
| -rw-r--r-- | BUILDING.md | 22 |
1 files changed, 12 insertions, 10 deletions
diff --git a/BUILDING.md b/BUILDING.md index 3a2eae8..6dfeddb 100644 --- a/BUILDING.md +++ b/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` |