GitLab

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 00aaea36)

Bug: 16874785

(cherry picked from commit e0c56efd)

Change-Id: I9c922ba019f648766fc399d1c4e35e789e25acd4

 Change lookup order during relocation so that
 ld_preloads always precede caller (unless caller
 is main executable).

 Asan needs this change in order to intercept libc->libc
 calls.

Bug: 15432753
Change-Id: If69aa16efe59aa35bb30e96feb83d08f1efbec86

...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 9e4ffa70)

Change-Id: I73f219a569917b2e4546c09436d7ef5231facc07

When enabling debug malloc, the snprintf calls in the linker fails to
update the buffer.

The problem is that snprintf makes a call to pthread_getspecific that
returns a valid pointer, but the data it points to is zero. This should
never happen and causes the snprintf to stop and do nothing.

Temporarily replace snprintf with a different implementation to work
around this issue.

Bug: 16874447
Bug: 17302493
Change-Id: I7a500f28adf153150cf2812fae745ff41f1c48d3

Merge "call uselocale() before freelocale() to make sure that g_local_key has a valid locale." into lmp-dev

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

This speeds up the debug malloc code by using the original unwinding code.
The only catch is that it has to link in the libc++ arm unwind code or
there will be crashes when attempting to unwind through libc++ compiled
code.

Bug: 16874447
Change-Id: Ifdbbcbd4137d668b25cf3c2bd59535e06ebfa5a7

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 57b7a611)

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

Bug: 17157793
Change-Id: I8290e240b92e5617f4c12c0eacad6e622e677b6a

Removes the leading underscores from __android_set_abort_message() and
moves its declaration into a public header file.

Bug: 17059126
Change-Id: I470c79db47ec783ea7a54b800f8b78ecbe7479ab
(cherry picked from commit ce6b1abb)
(cherry picked from commit 3a25ab95)

This reverts commit d97e9f54.

Bug: 17107521
Change-Id: I2b81ce2b5a4a2d166133a2626e49d81b6aef3672

Bug: 17062445
Change-Id: I027b186719654c2865b08c3fa83f90fa00c1e838
(cherry picked from commit fd5ee9ae)

Bug: 16874447
Change-Id: Ie54a73fd75529961195fa5173d9116d0ae897b03

Bug: 17011146

(cherry picked from commit ad5e8b50)

Change-Id: Ib1d3f8d6d38af98586658e01ed1ec79d2c5b4d42

This is an alternate, somewhat simpler, fix that makes it safe to
include both <atomic> and <stdatomic.h> from C++ code in either order.
It means that C code consistently uses one implementation of atomics
and C++ another.  We still have to make sure that those two
implementations interoperate correctly at runtime; in particular,
any flavor of atomic object needs to be represented exactly like the
underlying type, with the proper alignment constraint.

Bug:17007799
Change-Id: Iffcfc5220d8fa150f89dd083a121b24d23f268fc
(cherry picked from commit 019d3958)

Glibc calls theirs __ctype_get_mb_cur_max. Make ours match to cut down
on differences between bionic and glibc.

Bug: 11156955
Change-Id: Ib7231f01aa9676dff30aea0af25d597bfe07bc73

Has the effect of making ___mtctxres hidden.

Bug: 11156955
Change-Id: I5aa5f49344ad5ecb33f48737430561b329bcbb0d
(cherry picked from commit 891ec7a6)

Bug: 16874447
Change-Id: Ie3ce683fd1f58b837b8ea91dc798e561b8593356

(cherry picked from commit 51a22a12)

Bug: 17013324
Change-Id: I345c9d0fecc29d3626c5be01cc3c0ed1583ac361

 Do not run symbol lookup on already visited soinfos
 Not taking into account already visited libraries
 dramatically slows down dlsym in cases when there
 are multiple occurrences of a large library in
 dependency tree.

Bug: 16977077

(cherry picked from commit 042426ba)

Change-Id: I69d59e395e8112f119343e8a4d72fe31cd449f31

Now that -Bsymbolic is fixed, we can hide __libc_malloc_dispatch without
breaking ASAN.

Bug: 11156955
Change-Id: Ia2fc9b046a74e666b33aa6c6c5435f70a63b8021

The old definition only worked for functions that didn't use numbered
local labels. Upstream uses '666' not only as some kind of BSD in-joke,
but also because there's little likelihood of any function having
labels that high.

There's a wider question about whether we actually want to go via the
PLT at all in this code, but that's a question for another day.

Bug: 16906712
Change-Id: I3cd8ecc448b33f942bb6e783931808ef39091489

This fixes the build after the -Bsymbolic change.

Bug: 16853291
Change-Id: I989c9fec3c32e0289ea257a3bd2b7fd2709b6ce2
(cherry picked from commit bc9f9f25)

The property libc.debug.malloc.nobacktrace set to non-zero disables
getting backtracing when using mode 1 or mode 10.

Bug: 16874447

Change-Id: I7650ba9f4385b5110b743cab01e877fc69545b3c

Clean up the x86/x86_64 assembler. The motivator (other than reducing
confusion) was that asm.h incorrectly checked PIC rather than __PIC__.

Bug: 16823325

(cherry picked from commit 6b6364a7)

Change-Id: I89ca57fa0eb34a36de6cb11ea85f71054fce709d

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