This fixes the bug with using the libraries loaded
prior to android_set_target_sdk_version call.
Bug: http://b/22548808
Change-Id: I3ca2d367b0fa930a437bbb65f780834803d2ef0a
* Disable optimization only in gtest.h of atexit_test.c for arm/aarch64
to keep VTT for std::__1::basic_stringstream<char, std::__1::char_traits<char>,
std::__1::allocator<char> > to link with g++ compiled modules.
* bionic-unit-tests source files are not affected by clang x86_64 fp128 bug
so they can be compiled with clang.
BUG: 25643775
Change-Id: I3da2a0de61edcdca07b7fcd73a16de9da4a1f7d6
We should fall back to GMT if neither the environment variable nor the
system property is set. This is the case if you wipe a WiFi-only device,
because we currently only take the time zone from cell networks.
Bug: http://b/24773112
Change-Id: I90d236d4d492b6562d75021bd312030b91c1e298
Upstream tzcode said "On platforms with tm_zone, strftime.c now assumes it
is not NULL". Which is fine for any struct tm generated by tzcode, but not
necessarily true of a struct tm constructed by arbitrary code. In particular,
Netflix on Nexus Player was failing to start because they format "%Z" with
a struct tm whose tm_zone is null (the other fields are valid, but, yeah,
that's probably not intentional).
glibc takes a null tm_zone to mean "the current time zone", so let's do that
too. (Historically Android would use the empty string, and POSIX doesn't
clarify which of this is the appropriate behavior when tm_zone is null.)
Bug: http://b/25170306
Change-Id: Idbf68bfe90d143aca7dada8607742905188b1d33
When __cxa_thread_atexit_impl.cpp is compiled with clang on arm64,
Android cannot boot up.
BUG: 25662915
Change-Id: If997b544f43e956172ce605d86fe147d42fd39e0
New 3.8 clang/llvm can compile TLS code now.
* For x86_64, still disable clang due to f128 bug.
* For b/25643775, arm and arm64, disable clang in unit tests.
* Fix thread_local_test.cpp to compile with clang and
limit gcc workaround only to arm and aarch64.
BUG: 25643775
Change-Id: Iecd006bf1fc417dbcce2c63343a59c4bf1fa77ea
Root cause:
If start_routine thread exits before pthread_gettid_np is invokded, the "tid" field
will be cleared so that pthread_gettid_np will get "0" (which is cleared by kernel,
due to the flag "CLONE_CHILD_CLEARTID" is set while calling clone system call inside
pthread_create).
Proposed patch:
Use a mutex to guarantee pthread_gettid_np will be invoked and returned before the
start_routine exits
Signed-off-by: Junjie Hu <junjie.hu@mediatek.com>
Change-Id: I22411f1b0f7446d76a0373cef4ccec858fac7018
(cherry picked from commit 4f8010293506d4e08d184e66bf4af44ef3483611)
The current comment implies that we only strip sensitive
environment variables on executing a setuid program. This is
true but incomplete. The AT_SECURE flag is set whenever a
security transition occurs, such as executing a setuid program,
SELinux security transition, executing a file with file capabilities,
etc...
Fixup the comments.
Change-Id: I30a73992adfde14d6e5f642b3a1ead2ee56726be
