Trusty doesn't have setjmp.h and nor does it have threads.

Change-Id: I005f7a009a13e6632513be9fab2bbe62294519a4
Reviewed-on: https://boringssl-review.googlesource.com/4660
Reviewed-by: Adam Langley <agl@google.com>

Previously I've been using the Linaro toolchains and just building
static binaries. However, the Linaro toolchains have a broken
pthread_rwlock_wrlock—it does nothing and then unlocking corrupts the
lock.

Building with the Android NDK avoids this.

These build instructions depend on
https://github.com/taka-no-me/android-cmake which people will need to
clone into util/ if they want to use the Android NDK.

Change-Id: Ic64919f9399af2a57e8df4fb4b3400865ddb2427
Reviewed-on: https://boringssl-review.googlesource.com/4600
Reviewed-by: Adam Langley <agl@google.com>

NEON_FUNCTIONAL is set by default in crypto.c. Chromium calls
|CRYPTO_set_NEON_functional| before |SSL_library_init| and thus the
getauxval path for CPU-feature detection was resetting the functional
flag, even on broken processors.

This change means that, apart from the default, only
|CRYPTO_set_NEON_functional| will change the NEON_FUNCTIONAL flag.

BUG=469511

Change-Id: I3d4dbbd9f4a5e33539f8559f90289e706ad17451
Reviewed-on: https://boringssl-review.googlesource.com/4170
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>

Previously, if SIGILL was received between the signal handler being
installed and before the sigsetjmp, the process would longjmp to a
random location.

Change-Id: I9e6143a17ff3db0e1b00ece68fce161801461010
Reviewed-on: https://boringssl-review.googlesource.com/3950
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>

We assume that AArch64 systems are modern enough to have getauxval.

Change-Id: I4cc74f04ca5ed50b8ca1cfd00afeaaa01c6caca0
Reviewed-on: https://boringssl-review.googlesource.com/3280
Reviewed-by: Adam Langley <agl@google.com>

These two patches conflicted but, because it wasn't a textual conflict,
Gerrit didn't notice.

Change-Id: I53464127e5e71dfa2f6c8a8847b41968671c2047

Android didn't have getauxval until Jelly Bean (4.1). This means that
BoringSSL running on older Androids won't be able to detect NEON
support. (This is moot for Chromium because Chromium calls
android_getCpuFeatures and sets the NEON flag itself, but other users of
BoringSSL on Android probably won't do that.)

This change mirrors a little of what upstream does and tries running a
NEON instruction with a handler for SIGILL installed.

Change-Id: I853b85c37ffb049b240582d71fcf07adedc37a30
Reviewed-on: https://boringssl-review.googlesource.com/3190
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>

The Android SDK version against which Chromium builds is too old to
include sys/auxv.h. This change switches the ARM code to use a weak
pointer for getauxval and to hard code the aux value numbers.

It also switches the license on cpu-arm.c because there's no OpenSSL
left in there now.

Change-Id: I440cb9d533a06d8b245b189d8e5148fa33e29412
Reviewed-on: https://boringssl-review.googlesource.com/2880
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>

This is an initial cut at aarch64 support. I have only qemu to test it
however—hopefully hardware will be coming soon.

This also affects 32-bit ARM in that aarch64 chips can run 32-bit code
and we would like to be able to take advantage of the crypto operations
even in 32-bit mode. AES and GHASH should Just Work in this case: the
-armx.pl files can be built for either 32- or 64-bit mode based on the
flavour argument given to the Perl script.

SHA-1 and SHA-256 don't work like this however because they've never
support for multiple implementations, thus BoringSSL built for 32-bit
won't use the SHA instructions on an aarch64 chip.

No dedicated ChaCha20 or Poly1305 support yet.

Change-Id: Ib275bc4894a365c8ec7c42f4e91af6dba3bd686c
Reviewed-on: https://boringssl-review.googlesource.com/2801
Reviewed-by: Adam Langley <agl@google.com>

Otherwise, in C, it becomes a K&R function declaration which doesn't actually
type-check the number of arguments.

Change-Id: I0731a9fefca46fb1c266bfb1c33d464cf451a22e
Reviewed-on: https://boringssl-review.googlesource.com/1582
Reviewed-by: Adam Langley <agl@google.com>

Some phones have a buggy NEON unit and the Poly1305 NEON code fails on
them, even though other NEON code appears to work fine.

This change:

1) Fixes a bug where NEON was assumed even when the code wasn't compiled
   in NEON mode.

2) Adds a second NEON control bit that can be disabled in order to run
   NEON code, but not the Poly1305 NEON code.

https://code.google.com/p/chromium/issues/detail?id=341598

Change-Id: Icb121bf8dba47c7a46c7667f676ff7a4bc973625
Reviewed-on: https://boringssl-review.googlesource.com/1351
Reviewed-by: Adam Langley <agl@google.com>

Initial fork from f2d678e6e8 (1.0.2 beta).

(This change contains substantial changes from the original and
effectively starts a new history.)