Before aosp/1086558, this was needed, since we would have
_USING_LIBCXX defined, yet <atomic> was not available, so we'd run
into compiler issues. After that change, we're using
__has_include(<atomic>) so this is no longer an issue.
Test: build
Change-Id: Ia81d343000e7d90f07422120fc1e1eb5becb01aa
These hooks notify the HWASan runtime library whenever a library is loaded
or unloaded so that it can update its shadow memory.
Bug: 138159093
Test: walleye_hwasan-userdebug boots with+without https://reviews.llvm.org/D65770
Change-Id: I6caf2a6540ed2c0d94db444e806a3c7ba504cabb
These are old enough now that the latest devices will have kernels that
support them.
Also add basic doc comments to <sys/mman.h>.
Test: treehugger
Change-Id: I1b5ff5db0b6270f5c374287cac1d6a751a0259f5
Also, fix a bug in update_all.py when the syscalls file does not change.
Test: Builds and boots on a taimen.
Change-Id: If85b00daef2c176f804a0861894f5bbca9c6d5df
renameat2 is now exposed, my comment about timerfd was nonsense, and
it's worth documenting when and where the various syscalls appeared.
Bug: http://b/127675384
Test: treehugger
Change-Id: I84662398d39678df3ee7ce39add670337ff8abea
The cuttlefish folks are hitting this because the VDSO clock_gettime
falls back to the clock_gettime64 system call when given an invalid
clock.
Bug: http://b/138781460
Test: examined the generated .cpp files.
Change-Id: I98b311cd8652716eb6d45fb99308fdf952e79ba3
The AArch64 ELF specification originally specified these relocations:
R_AARCH64_TLS_DTPREL64 1028
R_AARCH64_TLS_DTPMOD64 1029
However, the GNU toolchain implemented them as:
R_AARCH64_TLS_DTPMOD64 1028
R_AARCH64_TLS_DTPREL64 1029
The AArch64 ELF specification has been updated to replace the relocations
with R_AARCH64_TLS_IMPDEF1 and with R_AARCH64_TLS_IMPDEF2, where each
implementation can choose which interpretation it implements, but with a
suggestion to follow the GNU behavior.
Also: remove the 64 suffixes from the TLS relocations. The newest version
of the AArch64 ELF specification (version f) also omits the suffixes, as
do the glibc headers.
Bug: http://b/123385182
Bug: https://bugs.llvm.org/show_bug.cgi?id=40507
Test: build device, it boots
Change-Id: Ie98b7624752982973f0ac969d646454a86784cab
Versioner is now a prebuilt in prebuilts/clang-tools and that project
has the Clang headers packaged with it. Use that dependency instead of
external/clang/lib/Headers. Use the linux-x86 path for both Linux and
Darwin since they are both the same.
Test: presubmit
Change-Id: I01ad4c05fe3301a2fdad3662377f78694af6cd81
Instead of maintaining a symbol ordering file, using the new
sort_bss_symbols_by_size property allows for symbol sorting at build
time.
Bug: 135754984
Test: Build and check the resulting libc.so has its bss symbols sorted.
Change-Id: I4a1cd6774dfe61b73f454bdf95b535db1f9fb1ac
We will put instrumentation in ART to write out Java heap memory
information on receipt of this signal.
Bug: 136210868
Test: Flash blueline-userdebug and boot
Change-Id: I63173a4051c46b8569faaf3064e1db1dbd0ea3fe
Bionic creates a single thread mapping to hold a thread's stack and static
TLS memory. Use PR_SET_VMA_ANON_NAME to name this region
"stack_and_tls:tid". dumpsys meminfo can report this region as "Stack"
memory.
The main thread's memory is instead named stack_and_tls:main, and the VMA
is renamed to stack_and_tls:main in a post-fork child.
For the main thread, and threads using pthread_attr_setstack, Bionic still
creates the stack_and_tls mapping, but it only has TLS memory in it.
Bug: http://b/134795155
Test: run "dumpsys meminfo" and verify that this CL increases the reported
stack memory usage from about 4MB to 21MB.
Change-Id: Id1f39ff083329e83426130b4ef94222ffacb90ae
Merged-In: Id1f39ff083329e83426130b4ef94222ffacb90ae
Bug: 136138882
Test: Ran malloc debug tests.
Test: Ran an app with backtrace_full and verified demangling working in
Test: log file.
Test: Enabled leak checking and verified that the logs include properly
Test: demangled.
Change-Id: Ic4fd9f1522451e867048ac1bea59d8c5ed0d3577
The previous check was causing some problems with platform builds
using the NDK. The new check is more accurate.
Move the C definitions from stdatomic.h to bits/stdatomic.h since
with the new check, we no longer can use the #undef trick to test
them.
Test: build platform NDK with stdatomic.h in pthread.h header
Test: stdatomic bionic-unit-tests
Change-Id: Ia0bc3cc8344f2ba4e6e55a52248fb6efee799d1d
This avoids art having a direct reference to bionic directories which
would prevent the bionic module from being unbundled from the runtime
module.
Bug: 134379140
Test: m droid
Change-Id: I9545767b76341fd01166b675bdd156f620d4f262
A bit of over-reliance on implementing pthread_cond_clockwait() in
terms of existing functions ended up with a bug that if the condition
variable was initialized to use CLOCK_MONOTONIC, then
pthread_cond_clockwait() would do the wrong thing.
This change corrects that and adds a test for this case.
Test: new and existing tests pthread_cond unit tests
Change-Id: I708d5dfbef95a67678db56dceda011f2f8fd1c5c
A future version of HWASAN will set pointer tags when taking the address of
a global. This means that we need to untag pointers in a couple of cases
where potential global pointers are passed to an interface that expects
untagged pointers:
- The WriteProtected class, whose only instances are globals, passes its
own address to mprotect. However, our device kernels do not currently
untag pointers passed to mprotect (the proposed upstream kernel patches
do, however, untag these pointers), so once HWASAN starts tagging global
pointers, this will start failing.
- The shadow_load function loads from a shadow that corresponds to the
address space bounds of loaded binaries. Since these address space
bounds are untagged, the pointer needs to be untagged to match.
Test: boots
Change-Id: I3f11ce6eb7261752e5ff6d039d04dd45516b236f
They're used by 32-bit sanitizers. We used to get these for free (as the
comment says), but the place we got them from changed. Just be explicit.
Longer-term we should fix how we build the sanitizers to only use the
canonical system calls, like they already do for arm64.
Bug: https://issuetracker.google.com/136777266
Test: builds
Change-Id: If80a8d47aa345aaaa8bed32b44f020e06e504d49
snprintf always calls free (on a null pointer) in its epilogue, which
results in infinite recursion if free calls a function that calls
bionic_trace_begin (e.g. when perfetto attempts to lock a mutex in
RecordFree).
Bug: http://b/137284735
Test: treehugger
Change-Id: I51c5b32e8f4e394be4602e06c7b94797df73c37b
Note that unlike the oem_ range that is used for the vendor
partitions, we do not create oem_<n> entries for these new reserved
ranges; they will only appear in getpwent()/getgrent() if there is an
entry in the corresponding passwd/group file.
Bug: 73062966
Test: can load AIDs from partitions other than vendor
Test: bionic-unit-tests
Change-Id: Ifcbbf202894adff948eaaba2a59e25c993611140
On systems where the tcache is disabled, the tcache clear option will
fail, and not really do a purge.
Bug: 137037462
Bug: 136236080
Test: Built taimen as malloc svelte and verified the M_PURGE mallopt
Test: call failed before this fix and passes afterwards.
Change-Id: Ib30e5f3e083a9c6d046adff30f2aa7eacaf6df10
__builtin_*_chk will emit warnings when things are trivially broken.
Emitting errors instead is probably better (and we can be a bit smarter
about how we emit code for trivially safe cases.)
Bug: 131861088
Test: checkbuild + bionic-unit-tests on blueline
Change-Id: I33957ad419922d0760304758ecb9bc8ad33e0b64
Plain __ for generated syscalls didn't mean it was a hidden symbol, it
just meant "please don't use this". We added ___ to signify that a
hidden symbol should be generated, but then we added the map files
anyway so you now have to explicitly export symbols. Given that, this
convention serves no particular purpose so we may as well just use the
nicer names have everything look the same.
Test: treehugger
Change-Id: If424e17a49c36f4be545f5d283c4561a6ea9c7ea
