| commit | c3f4612d83f345ef0bb0024ce6086a6a773324ca | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Dec 01 17:47:57 2020 -0500 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Tue Dec 01 23:49:03 2020 +0000 |
| tree | e48034a4454acf2125cd795bb7b4a2c9b13a9478 | |
| parent | eb57cc1e875d3137aa3cf723f3c525e253ddea9b [diff] |
Only accept little-endian ARM and MIPS variants in base.h. <openssl/base.h> checks for a supported platform, but we don't check endianness of ARM and MIPS, which are bi-endian. See https://crbug.com/1153312#c7. Switch this around. Documentation on which define is "official" is hard to come by, so I mostly mimicked Chromium. Chromium detects little-endian ARM and MIPS with __ARMEL__ and __MIPSEL__ respectively, without looking at __arm__ or __mips__. It uses __aarch64__ instead of __AARCH64EL__, but I think that's an oversight. I can get Clang to output for aarch64_be and that defines __aarch64__ with __AARCH64EB__. <openssl/arm_arch.h> (which we should simplify and align with base.h once this CL sticks) also normalizes to __ARMEL__ over __BYTE_ORDER__ and friends. Although, interestingly, arm_arch.h defines its own __ARMEL__ on GNUC aarch64, even though Clang does *not* define __ARMEL__ on aarch64. (I'm guessing this aligned for the benefit of the "armx" bi-arch asm files.) This value is based on __BYTE_ORDER__, not __ARMEL__, but it assumes GNUC arm always defines __ARMEL__, so I think it's reasonable to assume GNUC aarch64 always defines __AARCH64EL__. Given all this, probably the simplest thing that's most likely to work is to use __ARMEL__, __MIPSEL__, and __AARCH64EL__. Note this does not change the _M_* checks. _M_* are Windows's definitions, which I think we can reasonably assume come with an endianness opinion. (Windows' ARM and ARM64 ABIs mandate little-endian.) This aligns with Chromium. Update-Note: CPU processor defines are a mess. If a little-endian ARM or MIPS build breaks, some of the assumptions above may be wrong. In that case, the output $CC -dM -E - < /dev/null on the offending toolchain will be useful to fix it. If a big-endian ARM or MIPS build breaks, this is working as intended. Any resulting binaries weren't producing the right outputs. Change-Id: I2a9e662d09df119a71226e91716d84e7ac3792aa Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44324 Commit-Queue: Adam Langley <agl@google.com> 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: