commit | d80f17d5c94b21c4fb2e82ee527bfe001b3553f2 | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Wed Dec 29 15:34:37 2021 -0500 |
committer | Adam Langley <agl@google.com> | Fri Jan 07 18:41:53 2022 +0000 |
tree | c37dcefa7f2c7cf03da033752a497934764636aa | |
parent | a94c267787df4ac0517456231ebc7be40442895f [diff] |
Simplify __ARM_ARCH__ definition. OpenSSL's assembly files have a few places where we condition code on __ARM_ARCH__, the minimum target ARM revision. It currently only controls some pre-ARMv7 code. This symbol has, from what I can tell, the same semantics as __ARM_ARCH, defined in Arm C Language Extensions, and added in GCC 4.8 and Clang 3.2: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9e94a7fc5ab770928b9e6a2b74e292d35b4c94da;hp=25bab91e017eb1d6d93117f3da96fa9b43703190 https://github.com/llvm/llvm-project/commit/e98c4dbd1ef783b04f0d8276847076fb79a804e8 Those are over nine years old, so drop all the fallback code. Also fix arm_arch.h to be includable on non-ARM platforms. Some tools expect all public headers to be cleanly includable and arm_arch.h being "public" was getting in the way (see cl/416881417). Interestingly, arm_arch.h previously only computed __ARM_ARCH__ for __GNUC__ and Clang doesn't define __GNUC__ on Windows. That means we actually weren't defining __ARM_ARCH__ for Windows. But none of the aarch64 assembly has __ARM_ARCH__-gated code, so it works out. If it ever does, that CL smooths that over. I've gated the __ARM_(MAX_)_ARCH__ bits on __ASSEMBLER__ to avoid breaking no-asm Windows/aarch64 builds on MSVC. There aren't any uses in C. Update-Note: ARM assembly now requires the compiler define __ARM_ARCH. This is not expected to break Clang or GCC from the last 8 or 9 years. Change-Id: Id45e95406edeecf8dda11dce9e82418516e9de1f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50849 Reviewed-by: Adam Langley <agl@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: