Previously we call __sinit() lazily. But it is likely to cause data
races like in https://android-review.googlesource.com/#/c/183237/. So
we prefer to call __sinit() explicitly at libc initialization.
Bug: 25392375
Change-Id: I181ea7a4b2e4c7350b45f2e6c86886ea023e80b8
Currently we use __thread variable to store thread_local_dtors,
which makes tsan test fork_atexit.cc hang. The problem is as below:
The main thread creates a worker thread, the worker thread calls
pthread_exit() -> __cxa_thread_finalize() -> __emutls_get_address()
-> pthread_once(emutls_init) -> emutls_init().
Then the main thread calls fork(), the child process cals
exit() -> __cxa_thread_finalize() -> __emutls_get_address()
-> pthread_once(emutls_init).
So the child process is waiting for pthread_once(emutls_init)
to finish which will never occur.
It might be the test's fault because POSIX standard says if a
multi-threaded process calls fork(), the new process may only
execute async-signal-safe operations until exec functions are
called. And exit() is not async-signal-safe. But we can make
bionic more reliable by not using __thread in
__cxa_thread_finalize().
Bug: 25392375
Change-Id: Ife403dd7379dad8ddf1859c348c1c0adea07afb3
After ToolchainCflags were added to soong crt no longer needs to try to
recreate the bare minimum cflags for compiling for each architecture.
Also always use GCC to match crt.mk
Change-Id: I01a833ab70d989033c84f072e3660d060189688c
The anonymous namespace is introduced to
handle cases when linker can not find the
caller. This usually happens when caller
code was not loaded by dynamic linker;
for example mono-generated code.
Bug: http://b/25844435
Bug: http://b/22548808
Change-Id: I9e5b1d23c1c75bc78548d68e79216a6a943a33cf
Use blueprint's new anonymous embedded struct feature to move the arch
variant properties down a level, replacing arch.cortex_a9.srcs with
arch.arm.cortex_a9.srcs, while still supporting top-level properties
like arch.arm.srcs.
Change-Id: Ib41c80e3549440d5efdfd293a15cffa3f51a0fe4
It is reported by tsan that funlockfile() can unlock an unlocked mutex.
It happens when printf() is called before fopen() or other stdio stuff.
As FLOCKFILE(fp) is called before __sinit(), _stdio_handles_locking is false,
and _FLOCK(fp) will not be locked. But then cantwrite(fp) in __vfprintf()
calls__sinit(), which makes _stdio_handles_locking become true, and
FUNLOCKFILE(fp) unlocks _FLOCK(fp).
Change _stdio_handles_locking into _caller_handles_locking,
so __sinit() won't change its value. Add test due to my previous fault.
Bug: 25392375
Change-Id: I483e3c3cdb28da65e62f1fd9615bf58c5403b4dd
* Many processes, including adbd, failed to start in mips/mips64
emulator when libc.so was compiled by clang.
BUG: 25291096
Change-Id: If3434ebdca4a3a6bf6102b120ee838a7ab66cd74
Currently is_private_anonymous is calculated as true if _either_
MAP_PRIVATE or MAP_ANONYMOUS is set, which is a mistake.
According to Documentation/vm/ksm.txt, "KSM only merges anonymous
(private) pages, never pagecache (file) pages". MAP_PRIVATE can
still be set on file cache pages so in order to not redundantly
set MADV_MERGEABLE on pages that are not fitted for it, both
MAP_PRIVATE and MAP_ANONYMOUS should be set.
Along with this fix, add an extra check that the mapped page is
not a stack page before setting MADV_MERGEABLE for it. Stack pages
change too quickly and always end up in KSM 'page_volatile' list.
Change-Id: If4954142852f17cc61f02985ea1cb625a7f3dec6
If tsan is used, the following callchain can happen:
__libc_preinit() -> __libc_init_globals() ->
__libc_init_vdso() -> strcmp() -> __tsan_init()
-> sysconf(_SC_PAGE_SIZE) -> getauxval().
But __libc_auxv is initialized in __libc_init_common(),
after __libc_init_globals(). One simple way to fix
this is to initialize __libc_auxv at __libc_init_globals().
Bug: 25392375
Change-Id: I3893b1f567d5f3b7a8c881c0c1b8234b06b7751b
This removes another way to obtain objects larger than PTRDIFF_MAX. The
only known remaining hole is now jemalloc's merging of virtual memory
spans.
Technically this could be wrapped in an __LP64__ ifndef since it can't
occur on 64-bit due to the 1:1 split. It doesn't really matter either
way.
Change-Id: Iab2af242b775bc98a59421994d87aca0433215bd
In order to run tsan unit tests, we need to support pthread spin APIs.
Bug: 18623621
Bug: 25392375
Change-Id: Icbb4a74e72e467824b3715982a01600031868e29
If calling pthread_mutex_trylock from pthread_mutex_destroy, tsan
warns about an attempt to destroy a locked mutex.
Bug: 25392375
Change-Id: I5feee20e7a0d0915adad24da874ec1ccce241381
