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
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
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
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
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
Code developed for glibc or older versions of bionic might expect more
randomness than the BSD implementation provides.
Bug: 15829381
Change-Id: Ia5a908a816e0a5f0639f514107a6384a51ec157e
* Static linker optimizes protected local symbol
out of existence, which leads to test failure.
Disabling it for now.
Change-Id: I8de327e5073f98b64639f7a0bba3a273aa419884
If you make clone, fork, or vfork system calls directly, you're still
on your own, but we now do the right thing for the clone wrapper.
With this implementation, children lose the getpid caching, but we've
no reason to think that that covers any significant use cases.
Bug: 15387103
Change-Id: Icfab6b63c708fea830960742ec92aeba8ce7680d
In practice, with this implementation we never need to make a system call.
We get the main thread's tid (which is the same as our pid) back from
the set_tid_address system call we have to make during initialization.
A new pthread will have the same pid as its parent, and a fork child's
main (and only) thread will have a pid equal to its tid, which we get for
free from the kernel before clone returns.
The only time we'd actually have to make a getpid system call now is if
we take a signal during fork and the signal handler calls getpid. (That,
or we call getpid in the dynamic linker while it's still dealing with its
own relocations and hasn't even set up the main thread yet.)
Bug: 15387103
Change-Id: I6d4718ed0a5c912fc75b5f738c49a023dbed5189
This allows an easier way to share config parameters between unit tests
and the bionic code.
It also fixes a problem where the 32 bit bionic tests based on glibc, or
the cts list executable did not have the pvalloc,valloc tests.
Change-Id: Ib47942cb8a278252faa7498a6ef23e9578db544f
These were removed from POSIX 2004. Hides the header declarations for all
targets, and hides the symbols for LP64.
Bug: 13935372
Change-Id: Id592f67e9b7051517a05f536e1373b30162e669c
Implement these new functions for all of the debug malloc types.
Fix a number of bugs in the debug malloc functions related to overflow
conditions.
Fix a bug in dlpvalloc due to an overflow condition.
Fix various other bugs in the debug malloc functions.
Add new tests for malloc functions.
Bug: 11225066
Change-Id: Idf50f389603e2157645565bc15cd9365eec2e9dd
Remove the incorrect tests that use a negative offset for mmap without
a fd.
Add a small set of tests for mmap.
Bug: 15436969
Change-Id: Id537d33cd4cdc26dee6cdfa9bf9cf35754bce335
These were both removed from POSIX 2004, and we don't define an
implementation for getw(3). Keep the definition of put(3) on LP32 for
binary compatibility.
Bug: 13935372
Change-Id: Iba384b45093ac6d2d7c2d81f7980cd7701dd6f56
When we switched to 64 bit host build be default, we no longer build
the glibc unit tests. Fix that, and also set all host targets to build
multilib.
This change also changes the name of bionic-unit-tests-glibc to add
the suffix of 32 or 64 depending on the host type built.
Change-Id: Ife13f9d80f351750ff02825b086d44bb0c2df828
Without that fix the test fails with:
"error: comparison between signed and unsigned integer expressions" on x86,
due to the fact that char is signed on x86.
Change-Id: I44462d67c15c7e9b730ad5da52eb9c05e207d34b
Signed-off-by: Alexander Ivchenko <alexander.ivchenko@intel.com>
__memcmp16() should return an integer less than, equal to, or greater than
zero. However the tests looks for a specific value.
Change-Id: I06052f58f9ccc67146a3df9abb349c4bc19f090e
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
Reported on the OpenBSD list, but we already had the fix for one from FreeBSD,
and I think the other only affected ld80 anyway. Worth having tests thuogh.
Change-Id: Ic4bbeb2384fd578a3ef13e4907be83deda50815f
The bug here turned out to be that we hadn't increased the constant
corresponding to the maximum number of bytes in a character to match
our new implementation, so any character requiring more than a byte
in UTF-8 would break our printf family.
Bug: 15439554
Change-Id: I693e5e6eb11c640b5886e848502908ec5fff53b1
