tree e48034a4454acf2125cd795bb7b4a2c9b13a9478
parent eb57cc1e875d3137aa3cf723f3c525e253ddea9b
author David Benjamin <davidben@google.com> 1606862877 -0500
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 1606866543 +0000

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>