This change provides __restore/__restore_rt on x86 and __restore_rt on
x86_64 with unwinding information to be able to unwind through signal
frame via libgcc provided unwinding interface. See comments inlined for
more details.
Also remove the test that had a dependency on
__attribute__((cleanup(foo_cleanup))). It doesn't provide us with any
better test coverage than we have from the newer tests, and it doesn't
work well across a variety architectures (presumably because no one uses
this attribute in the real world).
Tested this on host via bionic-unit-tests-run-on-host on both x86 and
x86-64.
Bug: 17436734
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
(cherry picked from commit 50321e2e66)
Change-Id: Iba90e36958b00c7cc7db5eeebf888dc89ce4d619
replace lseek() and use pread() instead
add test for library_fd_offset > file_size case
Bug: 17762003
(cherry picked from commit a6c1279098)
Change-Id: Ie117c745081ee33d07db5341115ff6c8e98b0dec
Use $(BUILD_SYSTEM)/base_rules to build it as custom module, so that
it's exposed to utilities like mm/mmma etc.
Bug: 17887283
Bug: 17762003
(cherry picked from commit 667853d477)
Change-Id: I405797d16f20dc09e5d84b93b6727b634db2fc2c
When setting a repeat timer using the SIGEV_THREAD mechanism, it's possible
that the callback can be called after the timer is disarmed or deleted.
This happens because the kernel can generate signals that the timer thread
will continue to handle even after the timer is supposed to be off.
Add two new tests to verify that disarming/deleting doesn't continue to
call the callback.
Modify the repeat test to finish more quickly than before.
Refactor the Counter implementation a bit.
Bug: 18039727
Change-Id: I73192c915cdacf608521b1792c54e5af14a34907
Otherwise the gcc compiler warning doesn't show up.
Add -Wno-error to fortify related tests. Fortify related tests
are expected to be examples of bad programs, and in many
cases shouldn't compile cleanly. Rewriting them to compile
cleanly isn't feasible nor desirable.
Bug: 17784968
(cherry picked from commit 1aaa17802c)
Change-Id: Ib6df1a3f44b55b1fff222e78395c10c51cd39817
Reset soinfo version to 0.
Disable ifunc test for arm64 because of old toolchain
in lmp-mr1-dev branch
Note: this commit should be reverted in -plus-aosp branch.
Change-Id: I2d6d996d43bc35d5d4975c745779f43a988b31e6
Expanded test for recursive libs. Fixed bug with unnecessary
soinfo_free of already loaded library.
(cherry picked from commit a6ac54a215)
Change-Id: I6907c723d9fbdf6b2777f3f236b1e29b0843edd6
There are number of changes in the way IFUNC related relocations are done:
1. IRELATIVE relocations are now supported for x86/x86_64 and arm64.
2. IFUNC relocations are now relying on static linker to generate
them in correct order - this removes necessety of additional
relocation pass for ifuncs.
3. Related to 2: rela?.dyn relocations are preformed before .plt ones.
4. Ifunc are resolved on symbol lookup this approach allowed to avoid
mprotect(PROT_WRITE) call on r-x program segments.
Bug: 17399706
Bug: 17177284
(cherry picked from commit 9aea164457)
Change-Id: Ie19d900fc203beb93faf8943b0d06d534a6de4ad
Enable the -std=gnu++11 flag for libstdc++ static and
dynamic libs.
ScopeGuard uses DISABLE_ macros instead of '= delete';
(cherry picked from commit d9ff722661)
Change-Id: If2573d080770e18b36b56106f2369f7bb682cd3c
This patch fixes the problem with symbol search order
for dlsym(RTLD_DEFAULT/RTLD_NEXT, .) by loading libraries
and ld_preloads in correct order.
Bug: https://code.google.com/p/android/issues/detail?id=74255
Attempt: 2
(cherry picked from commit 14669a939d)
Change-Id: Id87540c96a2242220967b6fa5d84ddcd829e2b97
This patch fixes the problem with symbol search order
for dlsym(RTLD_DEFAULT/RTLD_NEXT, .) by loading libraries
and ld_preloads in correct order.
Bug: https://code.google.com/p/android/issues/detail?id=74255
(cherry picked from commit a3ad450a2e)
Change-Id: I1125de10272c84e4f075cbc72859c1f6b3e89943
This allows adding destructors to classes used
for global variables.
(cherry picked from commit 14241402de)
Change-Id: I1d8776130d1e01a8c53d23a2949f5010f4c96b16
ifuncs now work in i386 and x86_64 when called in the same library as
well as in a different library.
Bug:6657325
(cherry picked from commit c5a13efa9b)
Change-Id: I321d780bc2f9bd1baa749e1acacd2683aefe827b
It's not allowed for a shell user to create a fifo in /data/local/tmp.
Make the test do nothing if not run as root.
Bug: 17646702
Change-Id: I932262fa233eae8b5dd607a2398a47c50a208701
There were two problems here:
* This would fail when run with unlimited stack, because it didn't know
that bionic reports unlimited stacks as 8MiB.
* This would leave RLIMIT_STACK small, causing failures to exec (so the
popen and system tests would fail).
(cherry-pick of 27a9aed819 plus the
new ScopeGuard.h from a3ad450a2e3fb6b3fe359683b247eba20896f646.)
Bug: 17394276
Change-Id: I5b92dc64ca089400223b2d9a3743e9b9d57c1bc2
This is needed to make L work correctly, and bionic tests pass
again, after applying the equivalent of
commit 00aaea3645 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 32429606bf)
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 00aaea3645)
...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 9e4ffa7032)
Change-Id: I73f219a569917b2e4546c09436d7ef5231facc07
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 57b7a6110e)
Change-Id: I87e679ee1c0db8092f2d1221c8e7c1461545c5a4
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
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
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 1aec7c1a35)
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 b6cc8e00cd)
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 e03e1eac0b)
Change-Id: Ie4cca2c445127a0936ee2b96651a8e7204fbaffd
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
(cherry picked from commit 6b55ba54ef)
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
(cherry picked from commit 4916706cfe)
Change-Id: I5cb7a1c17b156456e4c4818e65f256eb8d045424
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
Bug: 16568314
(cherry picked from commit 21972b61ec)
Change-Id: Ifbc424be29e5650ec72a24df25dd35f24fdd5b3c
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.
Bug: 14292866
Change-Id: I9c83500ba9cbb209b6f496067a91bf69434eeef5
dlsym(3) with handle != RTLD_DEFAULT|RTLD_NEXT performs
breadth first search through the dependency tree.
Bug: 16653281
(cherry picked from commit aa0f2bdbc2)
Change-Id: I0ba8c2034ab341f8a279cdb4e2e7e47f1aef7897
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.
(cherry picked from commit f1837377d2)
Change-Id: I973d999c31c9ab89b5a7b709beff6486b93408f2
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
(cherry picked from commit 3e424d0a24)
Change-Id: I5882a6b48c80fea8ac6b9c27e7b9de10b202b4ff
