This patch provides several small optimizations to the
implementation of mutex locking and unlocking. Note that
a following patch will get rid of the global recursion
lock, and provide a few more aggressive changes, I
though it'd be simpler to split this change in two parts.
+ New behaviour: pthread_mutex_lock et al now detect
recursive mutex overflows and will return EAGAIN in
this case, as suggested by POSIX. Before, the counter
would just wrap to 0.
- Remove un-necessary reloads of the mutex value from memory
by storing it in a local variable (mvalue)
- Remove un-necessary reload of the mutex value by passing
the 'shared' local variable to _normal_lock / _normal_unlock
- Remove un-necessary reload of the mutex value by using a
new macro (MUTEX_VALUE_OWNER()) to compare the thread id
for recursive/errorcheck mutexes
- Use a common inlined function to increment the counter
of a recursive mutex. Also do not use the global
recursion lock in this case to speed it up.
Change-Id: I106934ec3a8718f8f852ef547f3f0e9d9435c816
This patch changes the implementation of pthread_once()
to avoid the use of a single global recursive mutex. This
should also slightly speed up the non-common case where
we have to call the init function, or wait for another
thread to finish the call.
Change-Id: I8a93f4386c56fb89b5d0eb716689c2ce43bdcad9
Fix dead loops in file ./bionic/libc/unistd/pathconf.c
Change-Id: I7a1e6bcd9879c96bacfd376b88a1f899793295c8
Author: Jin Wei <wei.a.jin@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
When forking of a new process in bionic, it is critical that it
does not allocate any memory according to the comment in
java_lang_ProcessManager.c:
"Note: We cannot malloc() or free() after this point!
A no-longer-running thread may be holding on to the heap lock, and
an attempt to malloc() or free() would result in deadlock."
However, as fork is using standard lib calls when tracing it a bit,
they might allocate memory, and thus causing the deadlock.
This is a rewrite so that the function cpuacct_add, that fork calls,
will use system calls instead of standard lib calls.
Signed-off-by: christian bejram <christian.bejram@stericsson.com>
Change-Id: Iff22ea6b424ce9f9bf0ac8e9c76593f689e0cc86
Pass kernel space sigset_t size to __rt_sigprocmask to workaround
the miss-match of NSIG/sigset_t definition between kernel and bionic.
Note: Patch originally from Google...
Change-Id: I4840fdc56d0b90d7ce2334250f04a84caffcba2a
Signed-off-by: Chenyang Du <chenyang.du@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Chars are signed for x86 -- correct the comparison semantics.
Change-Id: I2049e98eb063c0b4e83ea973d3fcae49c6817dde
Author: Liubov Dmitrieva <liubov.dmitrieva@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Fix the compile warning to let the libc.debug.malloc=10 works well
Due to unsuitable value comparison, which cause compiler optimize the
code of comparing two digits.
Change-Id: I0bedd596c9ca2ba308fb008da20ecb328d8548f5
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Author: liu chuansheng <chuansheng.liu@intel.com>
(1) in pthread_create:
If the one signal is received before esp is subtracted by 16 and
__thread_entry( ) is called, the stack will be cleared by kernel
when it tries to contruct the signal stack frame. That will cause
that __thread_entry will get a wrong tls pointer from the stack
which leads to the segment fault when trying to access tls content.
(2) in pthread_exit
After pthread_exit called system call unmap(), its stack will be
freed. If one signal is received at that time, there is no stack
available for it.
Fixed by subtracting the child's esp by 16 before the clone system
call and by blocking signal handling before pthread_exit is started.
Author: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
When running the stress test of pthread create/destroy, a crash may
oocur in __get_tls(). That is caused by the race condition with __set_tls( ):
Author: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
android linker doesn't check machine type, it may load some
libraries which it doesn't support sometimes.
Author: Zhenghua Wang <zhenghua.wang@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Pull in an updated version of capabilities.h from the linux
kernel.
This file was generated using the following command:
cd bionic/libc/kernel/
./tools/clean_header.py -u ../../../external/kernel-headers/original/linux/capability.h
Change-Id: I43c8f014954f543858006f24e60a2e69955349da
The function must be named __atomic_cmpxchg, not __android_cmpxchg.
This typo broke existing prebuilt binaries (they couldn't be loaded
at runtime anymore).
Change-Id: I25ca7d18329817f0056e616a0409113269ad7b1f
We can't easily tell the protocol family of the secondary network,
so try both and trust that the carrier has configured dns servers
according to the protocols supported on its network.
bug:5468224
Change-Id: If4f017573d313a6ad8354574076de6d63d43b444
Use tgkill instead of tkill to implement pthread_kill.
This is safer in the event that the thread has already terminated
and its id has been reused by a different process.
Change-Id: Ied715e11d7eadeceead79f33db5e2b5722954ac9
Allow the kernel to choose a memory location to put the
thread stack, rather than hard coding 0x10000000
Change-Id: Ib1f37cf0273d4977e8d274fbdab9431ec1b7cb4f
__atomic_cmpxchg and other related atomic operations did not
provide memory barriers, which can be a problem for non-platform
code that links against them when it runs on multi-core devices.
This patch does two things to fix this:
- It modifies the existing implementation of the functions
that are exported by the C library to always provide
full memory barriers. We need to keep them exported by
the C library to prevent breaking existing application
machine code.
- It also modifies <sys/atomics.h> to only export
always-inlined versions of the functions, to ensure that
any application code compiled against the new header will
not rely on the platform version of the functions.
This ensure that said machine code will run properly on
all multi-core devices.
This is based on the GCC built-in sync primitives.
The end result should be only slightly slower than the
previous implementation.
Note that the platform code does not use these functions
at all. A previous patch completely removed their usage in
the pthread and libstdc++ code.
+ rename arch-arm/bionic/atomics_arm.S to futex_arm.S
+ rename arch-x86/bionic/atomics_x86.S to futex_x86.S
+ remove arch-x86/include/sys/atomics.h which already
provided inlined functions to the x86 platform.
Change-Id: I752a594475090cf37fa926bb38209c2175dda539
We're going to modify the __atomic_xxx implementation to provide
full memory barriers, to avoid problems for NDK machine code that
link to these functions.
First step is to remove their usage from our platform code.
We now use inlined versions of the same functions for a slight
performance boost.
+ remove obsolete atomics_x86.c (was never compiled)
NOTE: This improvement was benchmarked on various devices.
Comparing a pthread mutex lock + atomic increment + unlock
we get:
- ARMv7 emulator, running on a 2.4 GHz Xeon:
before: 396 ns after: 288 ns
- x86 emulator in KVM mode on same machine:
before: 27 ns after: 27 ns
- Google Nexus S, in ARMv7 mode (single-core):
before: 82 ns after: 76 ns
- Motorola Xoom, in ARMv7 mode (multi-core):
before: 121 ns after: 120 ns
The code has also been rebuilt in ARMv5TE mode for correctness.
Change-Id: Ic1dc72b173d59b2e7af901dd70d6a72fb2f64b17
The computation of si->base assumed that the first entry in the
program header table is a PT_PHDR. This results in the dynamic
linker crashing with a SIGSEGV/MAPERR when trying to load some
of the NDK unit test programs, which happen to have an EXIDX
header first, followed byu a PHDR one.
This patch fixes the computation by parsing the program header
table, looking explicitely for the PHDR entry. This fixes the
load of the NDK unit test programs, and doesn't affect system
libraries.
Change-Id: Id18ea6037dbe950b5abbbce816c2960321f0b81d
For Honeycomb, we added proper file thread-safety for
all FILE* operations. However, we did implement that by
using an out-of-band hash table to map FILE* pointers
to phtread_mutex_t mutexes, because we couldn't change
the size of 'struct _sFILE' without breaking the ABI.
It turns out that our BSD-derived code already has
some support code to extend FILE* objects, so use it
instead. See libc/stdio/fileext.h
This patch gets rid of the hash table, and put the
mutex directly into the sFILE extension.
Change-Id: If1c3fe0a0a89da49c568e9a7560b7827737ff4d0
The old code didn't work because the kernel expects a 64-bit sigset_t
while the one provided by our ABI is only 32-bit. This is originally
due to the fact that the kernel headers themselves define sigset_t
as a 32-bit type when __KERNEL__ is not defined (apparently to cater
to libc5 or some similarly old C library).
We can't modify the size of sigset_t without breaking the NDK ABI,
so instead perform runtime translation during the call.
Change-Id: Ibfdc3cbceaff864af7a05ca193aa050047b4773f
Previously, the linker always loaded itself into the same
location in memory, which inhibited the effectiveness of Android's
ASLR implementation. Modify the linker code so it can be relocatable
and link itself at runtime.
Change-Id: Ia80273d7a00ff648b4da545f4b69debee6343968
Use LOCAL_NO_CRT to prevent linking against crtbegin.o, rather than
messing with build rules. This also prevents linking against crtend.o,
which isn't needed for the linker.
Change-Id: I0c5b9999be7e8676560fe145c1c033ffce8db4d1
