This is needed to make L work correctly, and bionic tests pass
again, after applying the equivalent of
commit 00aaea364501b3b0abe58dae461136159df1e356 there.
It makes the preexisting code that uses __sync implementations
much more useful, although we should no longer be exercising that
code in AOSP.
Specifically fixes:
We were invoking __has_extension and __has_builtin for GCC compilations.
They're clang specific. Restructured the tests.
The __sync implementation was not defining the LOCK_FREE macros.
ATOMIC_VAR_INIT was using named field initializations. These are a
C, not C++, feature, that is not supported by g++ 4.6.
The stdatomic bionic test still failed with 4.6 and glibc with our
questionable LOCK_FREE macro implementation. Don't run that piece
with 4.6.
In L, this is a prerequisite for fixing:
Bug:16880454
Bug:16513433
Change-Id: I9b61e42307f96a114dce7552b6ead4ad1c544eab
(cherry picked from commit 32429606bf696d3b2ca555f132a0d60c566d0bd0)
We seem to use this stdatomic.h sometimes, and slightly different prebuilts
at other times, making them all difficult to test, and making it unclear
which one we're testing. This generalizes the bionic header so that it
can be used directly as the prebuilt header as well. So long as they
don't diverge again, that should somewhat improve test coverage.
Use the correct builtin for atomic_is_lock_free.
Fix atomic_flag_init.
Turn on atomic tests even with __GLIBC__, since they now appear to pass.
Include uchar.h in stdatomic.h where needed.
Add a basic memory ordering test.
Fix bit-rotted comments in bionic tests makefile.
Prerequisite for fixing b/16880454 and
Bug:16513433
Change-Id: If6a14c1075b379395ba5d93357d56025c0ffab68
(cherry picked from commit 00aaea364501b3b0abe58dae461136159df1e356)
This is needed to make L work correctly, and bionic tests pass
again, after applying the equivalent of
commit 00aaea364501b3b0abe58dae461136159df1e356 there.
It makes the preexisting code that uses __sync implementations
much more useful, although we should no longer be exercising that
code in AOSP.
Specifically fixes:
We were invoking __has_extension and __has_builtin for GCC compilations.
They're clang specific. Restructured the tests.
The __sync implementation was not defining the LOCK_FREE macros.
ATOMIC_VAR_INIT was using named field initializations. These are a
C, not C++, feature, that is not supported by g++ 4.6.
The stdatomic bionic test still failed with 4.6 and glibc with our
questionable LOCK_FREE macro implementation. Don't run that piece
with 4.6.
In L, this is a prerequisite for fixing:
Bug:16880454
Bug:16513433
Change-Id: I9b61e42307f96a114dce7552b6ead4ad1c544eab
We already had the POSIX strerror_r, but some third-party code defines
_GNU_SOURCE and expects to get the GNU strerror_r instead.
This exposed a bug in the libc internal logging functions where unlike
their standard brethren they wouldn't return the number of bytes they'd
have liked to have written.
Bug: 16243479
Change-Id: I1745752ccbdc569646d34f5071f6df2be066d5f4
...rather than just what's already mapped in. This seems somewhat
contrary to POSIX's "All pages within the stack described by stackaddr
and stacksize shall be both readable and writable by the thread", but
it's what glibc does.
Bug: 17111575
(cherry picked from commit 9e4ffa7032eaab308876b8e3da86b05c3c613878)
Change-Id: I73f219a569917b2e4546c09436d7ef5231facc07
...rather than just what's already mapped in. This seems somewhat
contrary to POSIX's "All pages within the stack described by stackaddr
and stacksize shall be both readable and writable by the thread", but
it's what glibc does.
Bug: 17111575
Change-Id: If9e2dfad9a603c0d0615a8123aacda4946e95b2c
For tests that call uselocale(), the locale is stored in the
g_userlocale_key thread-specific key. If freelocale() is called later,
then g_uselocal_key points to a deleted pointer. CTS eventually calls
vfprintf to print the result, which calls MB_CUR_MAX and MB_CUR_MAX
accesses the deleted locale stored in g_uselocale_key, causing unpredictable
errors.
Fixed the tests by calling uselocale() with the old locale before
calling freelocale.
(cherry-pick of 8a46cf0fcf82b8c76e05be7e066ec854f974603a.)
Bug: 17299565
Change-Id: I87efa2a9b16999a11d587f68d3aeedcbe6ac8a2c
For tests that call uselocale(), the locale is stored in the
g_userlocale_key thread-specific key. If freelocale() is called later,
then g_uselocal_key points to a deleted pointer. CTS eventually calls
vfprintf to print the result, which calls MB_CUR_MAX and MB_CUR_MAX
accesses the deleted locale stored in g_uselocale_key, causing unpredictable
errors.
Fixed the tests by calling uselocale() with the old locale before
calling freelocale.
Bug: 17299565
Change-Id: I87efa2a9b16999a11d587f68d3aeedcbe6ac8a2c
On most architectures the kernel subtracts a random offset to the stack
pointer in create_elf_tables by calling arch_align_stack before writing
the auxval table and so on. On all but x86 this doesn't cause a problem
because the random offset is less than a page, but on x86 it's up to two
pages. This means that our old technique of rounding the stack pointer
doesn't work. (Our old implementation of that technique was wrong too.)
It's also incorrect to assume that the main thread's stack base and size
are constant. Likewise to assume that the main thread has a guard page.
The main thread is not like other threads.
This patch switches to reading /proc/self/maps (and checking RLIMIT_STACK)
whenever we're asked.
Bug: 17111575
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
(cherry picked from commit 57b7a6110e7e8b446fc23cce4765ff625ee0a105)
Change-Id: I87e679ee1c0db8092f2d1221c8e7c1461545c5a4
On most architectures the kernel subtracts a random offset to the stack
pointer in create_elf_tables by calling arch_align_stack before writing
the auxval table and so on. On all but x86 this doesn't cause a problem
because the random offset is less than a page, but on x86 it's up to two
pages. This means that our old technique of rounding the stack pointer
doesn't work. (Our old implementation of that technique was wrong too.)
It's also incorrect to assume that the main thread's stack base and size
are constant. Likewise to assume that the main thread has a guard page.
The main thread is not like other threads.
This patch switches to reading /proc/self/maps (and checking RLIMIT_STACK)
whenever we're asked.
Bug: 17111575
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
Change-Id: I1d4dbffe7bc7bda1d353c3a295dbf68d29f63158
We seem to use this stdatomic.h sometimes, and slightly different prebuilts
at other times, making them all difficult to test, and making it unclear
which one we're testing. This generalizes the bionic header so that it
can be used directly as the prebuilt header as well. So long as they
don't diverge again, that should somewhat improve test coverage.
Use the correct builtin for atomic_is_lock_free.
Fix atomic_flag_init.
Turn on atomic tests even with __GLIBC__, since they now appear to pass.
Include uchar.h in stdatomic.h where needed.
Add a basic memory ordering test.
Fix bit-rotted comments in bionic tests makefile.
Change-Id: If6a14c1075b379395ba5d93357d56025c0ffab68
This test only works if you're root (strictly: if you have permission to
CLONE_NEWNS), so it's useful to us when we're doing ad hoc testing (since
that's usually done as root), but it's not useful as part of CTS or when
running the tests on the host.
(cherry-pick of 84d0683a824fa02dbaa6d1b56a79223804b54e80.)
Bug: 16705621
Bug: 17170200
Change-Id: Ia92c871b15f7e45fc174bb59bc95540fd00ae745
This test only works if you're root (strictly: if you have permission to
CLONE_NEWNS), so it's useful to us when we're doing ad hoc testing (since
that's usually done as root), but it's not useful as part of CTS or when
running the tests on the host.
Bug: 16705621
Bug: 17170200
Change-Id: Ia92c871b15f7e45fc174bb59bc95540fd00ae745
This way it's a lot harder for us to screw up (since we should always
be including <sys/cdefs.h> anyway).
Bug: 14659579
Change-Id: I23070fff3296b0d1c683bb5e3a6e214146327d53
<features.h> is supposed to take user-settable stuff like _GNU_SOURCE
and _BSD_SOURCE and turn them into __USE_GNU and __USE_BSD for use in
the C library headers. Instead, bionic used to unconditionally define
_BSD_SOURCE and _GNU_SOURCE, and then test _GNU_SOURCE in the header
files (which makes no sense whatsoever).
Bug: 14659579
Change-Id: Ice4cf21a364ea2e559071dc8329e995277d5b987
1. Add test for __attribute__((constructor/destructor))
and static constructor
2. Compile C++ testlibs with -std=gnu++11
Change-Id: I67f9308144a0c638a51f111fcba8e1933fe0ba41
Reduce randomization of the test by (1) replacing random() & 255
with hard-coded char and (2) by making State *Iteration function
visit every possible alignment combination instead of 10 random ones.
Change-Id: I0ff0b4ca817ba9fbbcce53e09b25eb10a1a853c2
ifuncs now work in i386 and x86_64 when called in the same library as
well as in a different library.
Bug:6657325
Change-Id: Ic0c48b1b0a76cb90f36c20c79f68294cc3fd44a1
During pthread_exit, the keys are cleaned. Unfortunately, a call to
free occurs after the cleanup and the memory for some of the keys
is recreated when using jemalloc. The solution is to do the key
cleanup twice.
Also, modify the pthread_detach__leak test to be less flaky
when run on a jemalloc system.
Bug: 16513133
Change-Id: Ic17e8344bdc1ba053c4f5b6d827a4c19c57860c1
During pthread_exit, the keys are cleaned. Unfortunately, a call to
free occurs after the cleanup and the memory for some of the keys
is recreated when using jemalloc. The solution is to do the key
cleanup twice.
Also, modify the pthread_detach__leak test to be less flaky
when run on a jemalloc system.
Bug: 16513133
(cherry picked from commit 18d93f2793fad393b6aa6eae6afe1054958339d5)
Change-Id: Idb32e7f9b09e2c088d256ed9eb881df80c81ff8e
Previously this was hard coded to 4. This is only the case for UTF-8
locales.
As a side effect, this properly reports C.UTF-8 as the default locale
instead of C.
Change-Id: I7c73cc8fe6ffac61d211cd5f75287e36de06f4fc
(cherry picked from commit 1aec7c1a35b2d03038b194967d5ebdc8e2c24b80)
A mistake I made while cleaning this up the first time through.
mbstrtowcs(3) sets the src param to null if it finishes the string.
Change-Id: I6263646e25d9537043b7025fd1dd6ae195f365e2
(cherry picked from commit b6cc8e00cd562bd0f81fe44a6bc646540a862f32)
The memchr implementation for 64 bit fails if these conditions occur:
- The buffer is 32 byte aligned.
- The buffer contains the character in the first byte.
- The count sent in is zero.
The function should return NULL, but it's not.
Bug: 16676625
(cherry picked from commit e03e1eac0b7682884b6628df1305d34299680cb4)
Change-Id: Ie4cca2c445127a0936ee2b96651a8e7204fbaffd
A mistake I made while cleaning this up the first time through.
mbstrtowcs(3) sets the src param to null if it finishes the string.
Change-Id: I6263646e25d9537043b7025fd1dd6ae195f365e2
Previously this was hard coded to 4. This is only the case for UTF-8
locales.
As a side effect, this properly reports C.UTF-8 as the default locale
instead of C.
Change-Id: I7c73cc8fe6ffac61d211cd5f75287e36de06f4fc
The memchr implementation for 64 bit fails if these conditions occur:
- The buffer is 32 byte aligned.
- The buffer contains the character in the first byte.
- The count sent in is zero.
The function should return NULL, but it's not.
Bug: 16676625
Change-Id: Iab33cc7a8b79920350c72f054dff0e0a3cde69ce
dlsym(3) with handle != RTLD_DEFAULT|RTLD_NEXT performs
breadth first search through the dependency tree.
Bug: 16653281
Change-Id: I017a6975d1a62abb0218a7eb59ae4deba458e324
Also clean up the implementation of all the pty functions, add tests,
and fix the stub implementations of ttyname(3) and ttyname_r(3).
Bug: https://code.google.com/p/android/issues/detail?id=58888
Change-Id: I0fb36438cd1abf8d4e87c29415f03db9ba13c3c2
