| commit | fcec1397a411cbe4e27bd1428dad63adf207dc33 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Dec 12 13:58:22 2023 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Dec 12 20:57:47 2023 +0000 |
| tree | c057a9b7f941cf5bc2d6e2f8c0073c0cf5d5acc1 | |
| parent | 547221f5dc50e62543733cd65bd71bd97785afb6 [diff] |
Disable 32-bit Arm assembly optimizations on iOS The last iOS version that supported 32-bit was iOS 10, which I don't believe any of our consumers support anymore. (Chromium does not, neither does google/oss-policies-info.) Our iOS CI coverage comes from Chromium, so this means we don't actually have any test coverage for 32-bit iOS, only compile coverage. In addition to lacking any test coverage, 32-bit Arm assembly is more platform-dependent than one might expect, between different limitiations on patterns for PC-relative loads and lots of assembler quirks around what kinds of label expressions (which show up in PC-relative loads a lot) are allowed. Finally, since iOS in that era did not do runtime detection of features and relied on compiling a binary multiple times, the 32-bit assembly would never enable AES acceleration anyway, so it's not as impactful as on other platforms. Between all that, it's no longer worth enabling this. Disable it in target.h which, with the all the recent build simplifications, should be sufficient to disable this code. Update-Note: iOS on 32-bit Arm now disables assembly. This is unlikely to impact anyone. As far as I can tell, 32-bit Arm for iOS thoroughly does not exist anymore. Change-Id: If31208b42047377ad1b4fb0af6fee17334f18330 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64748 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
There are other files in this directory which might be helpful: