Not necessary (as demonstrated by the lack of this for x86), but this
saves one stack frame in aborts, which gets you one more useful stack
frame in logs and clustering etc, which improves your chances of finding
your bug.
Test: crasher64 abort
Change-Id: Ieb214f3b46520161edc1e53c0d766353b777d8ba
Those flags were used to suppress ABI tidy errors, but by now are not in
use anymore and can safely be removed.
Bug: 156513478
Change-Id: Ibc9625d139f933e48ebb4ddebe70d424f6231f3f
Signed-off-by: Matthias Maennich <maennich@google.com>
glibc maintainer Florian Weimer pointed out that glibc passes a null first
argument to riscv64 ifunc resolvers. While not super useful right now,
that does make it much easier to switch to providing arguments in future,
such as my favorite idea of passing a default set of hwprobe key/value
pairs, along with a count of how many pairs.
Test: treehugger
Change-Id: Ibe2148dc28aa6ad230e6324b6d725fe472b7ef33
Also de-pessimize time(), where the vdso entrypoint only exists on
x86/x86-64 anyway.
Bug: https://github.com/google/android-riscv64/issues/8
Test: strace
Change-Id: I14cb2a3130b6ff88d06d43ea13d3a825a26de290
Change a test to use a signal that does not trigger a tombstone.
Also changed the gwp_asan_integration.DISABLED_assert_gwp_asan_enabled
test to inherit from the SilentDeathTest to prevent tombstones
being generated.
Test: Ran tests and no tombstones generated.
Change-Id: I0f104704829dde692aa515a63dea1c6971278c29
A few death tests are not set to silence tombstones, so fix
all of those occurrences.
Test: Ran all death tests and no tombstones generated.
Change-Id: If2b54b1a3432edbd54076439d40527d966607f70
The new libc++_static.a platform prebuilt prefers to use this C11
function rather than the non-standard memalign.
Bug: http://b/175635923
Test: treehugger
Change-Id: I9c181568ba69c0508e400baac2cbb42b169c9768
A constructor could spawn a thread, which could call into the loader,
so the global loader mutex must be held.
Bug: http://b/290318196
Test: treehugger
Change-Id: I7a5249898a11fbc62d1ecdb85b24017a42a4b179
The set_allocation_limit_multiple_threads test could fail every
once in a while. So rewrite slightly so that the tests wait until
all of the threads are running before letting them start.
I also refactored the code to use std::thread instead of the raw
pthread functions.
Bug: 291672185
Test: Ran the test thousdands of times.
Change-Id: Ia0bdef93d58e0ff8266e551ed4a32e14ff829581
These all appear to be either musl bugs or underspecified corners of
the C standard, so rather than verify the musl behavior I've just
disabled the body of the test for musl.
Now that this is skipped, all the uchar tests are passing for bionic,
glibc, and musl.
Bug: None
Test: None
Change-Id: Icf88ef42e9b750ab45ba76bf8112967b00e72a9f
These are the same function for machines with binary floats (that is:
all machines), but ldexp() is in libc rather than libm, so we can't just
use an alias.
We were using this duplicate copy of the code, but upstream FreeBSD has
removed it, and I'd prefer to do the same.
Longer term, we should just move all of libm into libc (but keep an
empty libm for compatibility), but this is probably easier for now.
Test: treehugger
Change-Id: I1a1d6d4f1771316f791ad59c714a3a65aedefc81
Doesn't do anything for bionic (which is why this has gone unnoticed),
but it does change the locale for glibc and musl. After this patch,
all these tests pass on glibc. musl is still failing in
uchar.start_state, which I haven't finished investigating.
This should probably be a test fixture so it's harder to forget, but
there are a handful of tests here which don't call setlocale until
part way through the tests, and I'm not certain if that was attempting
to test some non-obvious behavior, or if that was just an accident. I
don't want to change that test behavior before understanding it
better, so this will do for now.
Bug: None
Test: ./tests/run-on-host.sh 64 --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh musl --gtest_filter="uchar.*"
Change-Id: Ib781a41893f021e336e67281070932f41f792318
This one forgot to set its locale, so it was passing on glibc (because
the sequence here wasn't valid in its default locale) and failing on
musl, both for the wrong reasons.
Bug: None
Test: ./tests/run-on-host.sh 64 --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh musl --gtest_filter="uchar.*"
Change-Id: Ic6bcd1836ba23c7010e2cde673a3beca73778021
Musl was treating 0xf0 as a valid character in its default locale. I
didn't dig into whether that was a musl bug or whether it was actually
translating whatever extended ASCII character that was into the
correct code point (tbh I don't know what the rule there is either).
Bug: None
Test: ./tests/run-on-host.sh 64 --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh musl --gtest_filter="uchar.*"
Change-Id: I0845fdee9a016ad67ccff3716129ff29f83a63d7
Also actually assign a bool to it. I'd originally written a #define
and apparently forgot to fix the value. I'm a bit surprised that clang
didn't complain.
Bug: None
Test: ./tests/run-on-host.sh 64 --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh glibc --gtest_filter="uchar.*"
Test: ./tests/run-on-host.sh musl --gtest_filter="uchar.*"
Change-Id: Iac46bc9c48fd70853d5c447e812e25e617281d2b
This gives us C11 Annex K's qsort_s(), which -- despite being Annex K --
is potentially useful in that it resolves the long-standing argument
about what the signature of qsort_r() is supposed to be. I'll import
it here first, and worry about actually using it separately (given that
glibc/musl and macOS/iOS don't have it; only Windows and [now] FreeBSD,
but not even the other BSDs).
For now, though, this change is a no-op.
Bug: http://b/17203231
Bug: http://b/31807750
Test: treehugger
Change-Id: Id8d2916b608ba8251df8643694da542e9b11eaae
More interesting changes to come, but there's enough of this noise I'm
separating it out...
Test: treehugger
Change-Id: I0efc0ac860a147112369df7561ee48a92a2a5e84
