We have bool here. Also the comments were a mix of two styles.

Change-Id: I7eb6814b206efa960ae7e6e1abc14d64be6d61cf
Reviewed-on: https://boringssl-review.googlesource.com/11602
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>

This reverts commit 7b9bbd9639. This seems
to cause some problem linking with gold in Chromium:

../../third_party/binutils/Linux_x64/Release/bin/ld.gold: warning: Cannot export local symbol 'free'
../../third_party/binutils/Linux_x64/Release/bin/ld.gold: warning: Cannot export local symbol 'malloc'
../../third_party/binutils/Linux_x64/Release/bin/ld.gold: warning: Cannot export local symbol 'realloc'
../../third_party/binutils/Linux_x64/Release/bin/ld.gold: error: treating warnings as errors

The same error in https://crbug.com/368351 implies we're actually
causing the compiler to make some assumptions it shouldn't make. The
obvious fix of marking things as visible causes crashes when built with
ASan (ASan's malloc interceptors and ours are conflicting somehow).
Revert this for now. We should study how ASan's interceptors work and
figure out how to make these two coexist.

BUG=655938

Change-Id: Iaad245d1028c442bd924d46519b20115d37a57c4
Reviewed-on: https://boringssl-review.googlesource.com/11604
Reviewed-by: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>

They just need a different name for the real malloc implementations.

Change-Id: Iee1aac1133113d628fd3f9f1ed0335d66c6def24
Reviewed-on: https://boringssl-review.googlesource.com/11400
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>

If gdb is attached, it's convenient to be able to continue running.

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

Per malloc(3):

    The  UNIX  98  standard requires malloc(), calloc(), and realloc() to set
    errno to ENOMEM upon failure.  Glibc assumes that this is done (and the
    glibc versions of these routines do this); if you use a private malloc
    implementation that does not set errno, then certain library routines may
    fail without having a reason in errno.

Notably, thread_test otherwise fails an assertion deep in glibc.

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

At some point we might need to make this defined by the consumer.

BUG=495146

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

Currently far from passing and I haven't even tried with a leak checker yet.
Also bn_test is slow.

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

We can't actually catch this with MSan because it requires all code be
instrumented, so it needs a NO_ASM build which no disables that code. valgrind
doesn't notice either, possibly because there's some computation being done on
it. Still, we shouldn't use uninitialized memory.

Also get us closer to being instrumentable by MSan, but the runner tests will
need to build against an instrumented STL and I haven't tried that yet.

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

ASan's own malloc interceptor isn't compatible with this mechanism; it doesn't
see calls to __libc_malloc.

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

I'm guessing a previous iteration used dlsym to look up the real malloc.

Change-Id: I18be9ef4db4ed059400074c8507d4e2fea882fbc
Reviewed-on: https://boringssl-review.googlesource.com/4100
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>

This commit fixes a number of crashes caused by malloc failures. They
were found using the -malloc-test=0 option to runner.go which runs tests
many times, causing a different allocation call to fail in each case.

(This test only works on Linux and only looks for crashes caused by
allocation failures, not memory leaks or other errors.)

This is not the complete set of crashes! More can be found by collecting
core dumps from running with -malloc-test=0.

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