On 32-bit MIPS, 64-bit atomic ops are achieved through locks.
So allow the test to fail for atomic_intmax_t on 32-bit MIPS.
Change-Id: I78e7807e50f899a0fea0d5b388d9ebb53228aaa0
I've also added insque(3) and remque(3) (from NetBSD because the OpenBSD
ones are currently broken for non-circular lists).
I've not added the three hash table functions that should be in this header
because they operate on a single global hash table and thus aren't likely
to be useful.
Bug: https://code.google.com/p/android/issues/detail?id=73719
Change-Id: I97397a7b921e2e860fd9c8032cafd9097380498a
Save and restore floating point registers via 64-bit
load/stores when possible. Use assembler's builtin macro
ops to generate pairs of 32-bit load/stores on Mips I cpus.
Some cpus or FR modes have only 16 even-numbered dp fp regs.
This is exposed by _MIPS_FPSET, defined by existing compilers.
Change-Id: I7f617a3ffea8da41c402ef3a68ab32c91d3d7622
PR_GET_DUMPABLE is used by an application to indicate whether or
not core dumps / PTRACE_ATTACH should work.
Security sensitive applications often set PR_SET_DUMPABLE to 0 to
disable core dumps, to avoid leaking sensitive memory to persistent
storage. Similarly, they also set PR_SET_DUMPABLE to zero to prevent
PTRACE_ATTACH from working, again to avoid leaking the contents
of sensitive memory.
Honor PR_GET_DUMPABLE when connecting to debuggerd. If an application
has said it doesn't want its memory dumped, then we shouldn't
ask debuggerd to dump memory on its behalf.
FORTIFY_SOURCE tests: Modify the fortify_source tests to set
PR_SET_DUMPABLE=0. This reduces the total runtime of
/data/nativetest/bionic-unit-tests/bionic-unit-tests32 from approx
53 seconds to 25 seconds. There's no need to connect to debuggerd
when running these tests.
Bug: 16513137
Change-Id: Idc7857b089f3545758f4d9b436b783d580fb653f
This doesn't require us to change any of the syscall implementations
because (a) the LP32 ones have sizeof(int) == sizeof(long) anyway,
which is how we never noticed this bug before and (b) the LP64 ones
all use a 64-bit register for the result (and for the syscall number
too).
Bug: https://code.google.com/p/android/issues/detail?id=73952
Change-Id: I9866c3579a7a94de27bfbe80ad7a822c3183c7fb
This also brings our copy of strftime.c much closer to upstream, though
we still have several GNU extensions and hacks to deal with Android32's
broken time_t.
Bug: 15765976
Change-Id: Ic9ef36e8acd3619504ecc4d73feec2b61fd4dfa1
It seemed like a clever trick to use the internal log message formatting
code in syslog(3), but on reflection that means you can't (for example)
format floating point numbers. This patch switches us over to using good
old vsnprintf(3), even though that requires us to jump through a few hoops.
There's no obvious way to unit test this, so I wrote a little program and
ran that.
(cherry-pick of b1b60c30bf321c0fc02264b953b5c16c49d34457.)
Bug: 14292866
Change-Id: I9c83500ba9cbb209b6f496067a91bf69434eeef5
Explicitly tell 32-bit links that they are doing 32-bit links.
This is needed when using united 32-bit and 64-bit toolchains.
This is harmless when using older separate 32-only toolchains.
Change-Id: I70cbd3f5867e59b1f6f829793444242fb0894aa6
The getentropy_linux.c is lightly modified to build on Android, but we're now
completely in sync with upstream OpenBSD's arc4random implementation.
Change-Id: If32229fc28aba908035fb38703190d41ddcabc95
Since we don't have syslogd on Android and you can't run one on a non-rooted
device, it's more useful if syslog output just goes to the regular Android
logging system.
Bug: 14292866
Change-Id: Icee7f088b97f88ccbdaf471b98cbac7f19f9210a
The len parameter is a _maximum_ length. The previous code was treating
it as an exact length, causing the following typical call to fail:
mbsrtowcs(out, &in, sizeof(out), state); // sizeof(out) > strlen(in)
Change-Id: I48e474fd54ea5f122bc168a4d74bfe08704f28cc
