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
As of aosp/1086558, stdatomic.h directly checks for the presence of
<atomic> instead of checking _USING_LIBCXX, so these lines are
obsolete.
Test: build
Change-Id: Icfdb47b3ad109421b3413041f3d3027e2c0b518e
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
https://reviews.llvm.org/D58797 added several new compile time
_FORTIFY_SOURCE diagnostics. This broke clang_fortify_tests:
FAILED: out/target/product/walleye/obj/STATIC_LIBRARIES/bionic-compile-time-tests2-clang++_intermediates/clang_fortify_tests.o
error: 'warning' diagnostics seen but not expected:
Line 159: 'memcpy' will always overflow; destination buffer has size 8, but size argument is 9
Line 161: 'memmove' will always overflow; destination buffer has size 8, but size argument is 9
Line 165: 'memset' will always overflow; destination buffer has size 8, but size argument is 9
Line 183: 'strncpy' size argument is too large; destination buffer has size 8, but size argument is 9
Line 185: 'stpncpy' size argument is too large; destination buffer has size 8, but size argument is 9
Line 189: 'strncat' size argument is too large; destination buffer has size 8, but size argument is 9
Line 227: 'strncpy' size argument is too large; destination buffer has size 4, but size argument is 5
Line 232: 'stpncpy' size argument is too large; destination buffer has size 4, but size argument is 5
Line 242: 'strncat' size argument is too large; destination buffer has size 4, but size argument is 5
Line 490: 'snprintf' size argument is too large; destination buffer has size 8, but size argument is 9
Line 495: 'vsnprintf' size argument is too large; destination buffer has size 8, but size argument is 9
error: 'note' diagnostics seen but not expected:
File bionic/libc/include/bits/fortify/fcntl.h Line 50: 'open' has been explicitly marked unavailable here
File bionic/libc/include/bits/fortify/fcntl.h Line 102: 'open64' has been explicitly marked unavailable here
File bionic/libc/include/bits/fortify/fcntl.h Line 75: 'openat' has been explicitly marked unavailable here
File bionic/libc/include/bits/fortify/fcntl.h Line 121: 'openat64' has been explicitly marked unavailable here
File bionic/libc/include/bits/fortify/stdio.h Line 68: 'sprintf' has been explicitly marked unavailable here
16 errors generated.
Bug: 131328001
Bug: 138701853
Test: Build with r365631 toolchain
Change-Id: I103ecb7b3abcf4b5cfc4f36ccab69e03d0976275
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
When relocating a DSO, it is not unusual to have consecutive
relocations using the same symbol. In this case, it is wasteful to
perform the same symbol lookup. This change implements an 1-entry
symbol cache so that symbol lookup results are reused in such scenario.
Test: On cuttlefish, enable STATS in linker_debug.h. Boot and see RELO
STATS in logcat showing cache hits. Hit rate seen is mostly
within 15% to 45%.
Change-Id: I84783d3b9a6ac9e39ed7fb45e58f6b3c012478d0
The demangler is moving out of libc++abi to save on bloat.
Test: make checkbuild
Bug: http://b/138245375
Change-Id: I7402894bb326f524388c9efdf86509dad50f2018
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
