| commit | 12316ab445eef5317391a94bef733fa6ff175173 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Mon Dec 11 21:23:27 2023 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Jan 26 18:15:01 2024 +0000 |
| tree | e2e8fc69cd888477eb155c68279e2ad32c5b0d0d | |
| parent | 7cb8df579329b70cd4ede09d6d228636b8e31e89 [diff] |
sha: Move Armv7 dispatching to C (reland) This is a reland of https://boringssl-review.googlesource.com/c/boringssl/+/64749, which was reverted in https://boringssl-review.googlesource.com/c/boringssl/+/65328 due to issues in Arm mode (i.e. not Thumb mode) builds that target Armv6+ instead of Armv7+. The issue was that sha256_block_data_order_nohw has slightly different sizes depending on __ARM_ARCH. Prior to moving the dispatch, the sizes worked out such that they were always encodable in ADR. After moving the dispatch, the instructions got shorter, such that the Armv7+ build still worked, but the Armv6+ build needed to encode an offset of 0x1060 (previously 0x1080), which does not fit. See https://alisdair.mcdiarmid.org/arm-immediate-value-encoding/ for details on Arm's very fussy immediate value encoding. It's not the only form used for ADR (Thumb2 works very differently), but it's the applicable one here. While we could shuffle things around, this is all far too fragile. Just use the LDR; ADD pattern we used for the other function. ADRL would avoid a load (it splits the offset into two constants without a constant bank), but that's a pseudo-instruction that's only supported by gas. clang-assembler didn't want to implement it. Android have a macro at https://android.googlesource.com/platform/ndk/+/refs/heads/master/docs/ClangMigration.md#arm, but it didn't work for me when I tried it. Also, searching around, it sounds like ADRL in gas only works in Arm mode and not Thumb mode? We could probably work through all that, but the compiler emits constant banks on 32-bit Arm all the time. (I got this pattern from Clang's output.) This is probably not worth the trouble. Bug: 673 Change-Id: I165544764a931b293aa66fb3fc9bb8f01eeb8092 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65808 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: 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: