Bug: http://b/197147102
Bug: http://b/214080353
With https://reviews.llvm.org/D77491, clang got stricter when issuing
diagnostics regarding builtin functions.
https://reviews.llvm.org/D112024 adds a diagnose_as_builtin attribute
which lets it diagnose builtins even though their signature is slightly
different. This patch adds diagnose_as_builtin attribute as needed.
Versioner is built with an older clang so it doesn't recognize this
attribute. So this is added with a preprocessor check on clang
versions. We can remove the version check once versioner gets updated
shortly after the compiler update.
Test: mmma bionic/tests with clang-r445002
Change-Id: I3d0d63ecdbea0cffe97eb5110e2d9f2a7595a38e
Bug: http://b/214080353
The wrong alignment to aligned_alloc() is deliberate. Silence the
warning around the test.
Test: build with clang-r445002
Change-Id: I73bad7775423c908c2bbe1c550e8ce5aeede129d
The first time should_trace() returns true, bionic_trace_begin() calls
open() on trace_marker.
The problem is that open() can call bionic_trace_begin(). We've observed
this happening, for example when:
* fdtrack is enabled. dlopen("libfdtrack.so") can be used to enable
fdtrack on a process.
* ThreadA is busy unwinding inside fdtrack and is holding an fdtrack
internal mutex.
* ThreadB calls bionic_trace_begin() for the first time since the
property "debug.atrace.tags.enableflags" contains ATRACE_TAG_BIONIC.
* ThreadB calls open("/sys/kernel/tracing/trace_marker"). Since fdtrack
is enabled, ThreadB tries to do unwinding as well.
* ThreadB, inside fdtrack's unwinding tries to grab the same mutex that
ThreadA is holding.
* Mutex contention is reported using bionic_systrace, therefore
bionic_trace_begin() is called again on ThreadB.
* ThreadB tries to grab g_lock in bionin_systrace.cpp, but that's
already held by ThreadB itself, earlier on the stack. Therefore
ThreadB is stuck.
I managed to reproduce the above scenario by manually pausing ThreadA
inside unwinding with a debugger and letting ThreadB hitting
bionic_trace_begin() for the first time.
We could avoid using g_lock while calling open() (either by releasing
g_lock and reacquiring it later, or by using atomics), but
bionic_trace_begin() would try to call open() again. In my tests, open()
does not call bionic_trace_begin() a third time, because fdtrack has
reentrancy protection, but there might be another code path inside open
that calls bionic_trace_begin again (it could be racy or only happen in
certain configurations).
This commit fixes the problem by implementing reentrancy protection in
bionic_systrace.
Sample callstack from ThreadA deadlocked before the fix:
```
* frame #0: 0x0000007436db077c libc.so`syscall at syscall.S:41
frame #1: 0x0000007436db0ba0 libc.so`bionic_trace_begin(char const*) [inlined] __futex(ftx=0x000000743737a548, op=<unavailable>, value=2, timeout=0x0000000000000000, bitset=-1) at bionic_futex.h:45:16
frame #2: 0x0000007436db0b8c libc.so`bionic_trace_begin(char const*) [inlined] __futex_wait_ex(ftx=0x000000743737a548, value=2) at bionic_futex.h:66:10
frame #3: 0x0000007436db0b78 libc.so`bionic_trace_begin(char const*) [inlined] Lock::lock(this=0x000000743737a548) at bionic_lock.h:67:7
frame #4: 0x0000007436db0b74 libc.so`bionic_trace_begin(char const*) [inlined] should_trace() at bionic_systrace.cpp:38:10
frame #5: 0x0000007436db0b74 libc.so`bionic_trace_begin(message="Contending for pthread mutex") at bionic_systrace.cpp:59:8
frame #6: 0x0000007436e193e4 libc.so`NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*) [inlined] NonPI::NormalMutexLock(mutex=0x0000007296cae9f0, shared=0, use_realtime_clock=false, abs_timeout_or_null=0x0000000000000000) at pthread_mutex.cpp:592:17
frame #7: 0x0000007436e193c8 libc.so`NonPI::MutexLockWithTimeout(mutex=0x0000007296cae9f0, use_realtime_clock=false, abs_timeout_or_null=0x0000000000000000) at pthread_mutex.cpp:719:16
frame #8: 0x0000007436e1912c libc.so`::pthread_mutex_lock(mutex_interface=<unavailable>) at pthread_mutex.cpp:839:12 [artificial]
frame #9: 0x00000071a4e5b290 libfdtrack.so`std::__1::mutex::lock() [inlined] std::__1::__libcpp_mutex_lock(__m=<unavailable>) at __threading_support:256:10
frame #10: 0x00000071a4e5b28c libfdtrack.so`std::__1::mutex::lock(this=<unavailable>) at mutex.cpp:31:14
frame #11: 0x00000071a4e32634 libfdtrack.so`unwindstack::Elf::Step(unsigned long, unwindstack::Regs*, unwindstack::Memory*, bool*, bool*) [inlined] std::__1::lock_guard<std::__1::mutex>::lock_guard(__m=0x0000007296cae9f0) at __mutex_base:104:27
frame #12: 0x00000071a4e32618 libfdtrack.so`unwindstack::Elf::Step(this=0x0000007296cae9c0, rel_pc=66116, regs=0x0000007266ca0470, process_memory=0x0000007246caa130, finished=0x0000007ff910efb4, is_signal_frame=0x0000007ff910efb0) at Elf.cpp:206:31
frame #13: 0x00000071a4e2b3b0 libfdtrack.so`unwindstack::LocalUnwinder::Unwind(this=0x00000071a4ea1528, frame_info=<unavailable>, max_frames=34) at LocalUnwinder.cpp:102:22
frame #14: 0x00000071a4e2a3ec libfdtrack.so`fd_hook(event=<unavailable>) at fdtrack.cpp:119:18
frame #15: 0x0000007436dbf684 libc.so`::__open_2(pathname=<unavailable>, flags=<unavailable>) at open.cpp:72:10
frame #16: 0x0000007436db0a04 libc.so`bionic_trace_begin(char const*) [inlined] open(pathname=<unavailable>, flags=524289) at fcntl.h:63:12
frame #17: 0x0000007436db09f0 libc.so`bionic_trace_begin(char const*) [inlined] get_trace_marker_fd() at bionic_systrace.cpp:49:25
frame #18: 0x0000007436db09c0 libc.so`bionic_trace_begin(message="pthread_create") at bionic_systrace.cpp:63:25
```
Bug: 213642769
Change-Id: I10d331859045cb4a8609b007f5c6cf2577ff44df
Unfortunately we have discovered that some applications in the wild
are using PAC instructions incorrectly. To keep those applications
working on PAC enabled devices, disable PAC in application processes
for now.
Bug: 212660282
Change-Id: I3030c47be9d02a27505bd4775c1982a20755758c
This was pretty broken. I think anything using this was being given
always-available annotations for everything but 32-bit x86? Treehugger
should complain loudly if this was actually impacting anything though.
I suspect not since the only user of this mode is mainline which
doesn't target far back enough to have arch-specific introduction
guards.
Test: treehugger
Bug: None
Change-Id: I64e96a89d83e64512e661e88915c48a091198992
Definitions for these are provided in libandroid_support for API
levels that do not expose this in the stubs. For the rare cases where
libandroid_support is not being used this will result in a lower
quality diagnostic (undefined reference instead of "not available
until API 21"), but other fixes would also have that behavior because
the libandroid_support headers are *always* available, even if
libandroid_support won't be linked.
Test: Reverted xfailed tests for #1108 and reran tests with this
Bug: https://github.com/android/ndk/issues/1108
Change-Id: I371f5b9d7caeef8dc7c80f2f6d11280ecba119c9
When we added the fast path for the common case of ASCII, we forgot to
remove the now-dead code that handled the 1-byte case later in these
functions. This was obvious from the code coverage data.
Note that the 16-bit variants are unaffected because they're implemented
as calls to the 32-bit variants with extra range checks/surrogate
handling surrounding the call.
Test: treehugger
Change-Id: Ibd40f823519acb9aae8037bdeb3f9c5e36b9d9a6
A decent chunk of the logcat profile is spent formatting the timestamps
for each line, and most of that time was going to snprintf(3). We should
find all the places that could benefit from a lighter-weight "format an
integer" and share something between them, but this is easy for now.
Before:
-----------------------------------------------------------
Benchmark Time CPU Iterations
-----------------------------------------------------------
BM_time_strftime 781 ns 775 ns 893102
After:
-----------------------------------------------------------
Benchmark Time CPU Iterations
-----------------------------------------------------------
BM_time_strftime 149 ns 147 ns 4750782
Much of the remaining time is in tzset() which seems unfortunate.
Test: treehugger
Change-Id: Ie0f7ee462ff1b1abea6f87d4a9a996d768e51056
clang was getting in the way of a strftime(3) optimization, and smaller
hammers weren't working, and this seems like the right choice for libc
anyway? If we have code that can usefully be optimized, we should do it
in the source. In general, though, no libc/libm author should be
ignorant of memset(3) or memcpy(3), and would have used it themselves if
it made sense. (And the compiler isn't using profiling data or anything;
it's just always assuming it should use the functions, and doesn't
consider whether the cost of the calls can be amortized or not.)
Test: treehugger
Change-Id: Ia7e22623e47bfbfcfe46c1af0d95ef7e8669c0f6
The implementation of FUSE BPF requires the FUSE daemon to access BPF
functionalities, i.e., to get the fd of a pinned BPF prog and to update
maps.
In Android the FUSE daemon is part of MediaProvider which, belonging to
the apps domain, can only access the subset of syscalls allowed by
seccomp, of which bpf() is currently blocked.
This patch removes this limitation by adding the bpf() syscall to the
allowed seccomp syscalls.
Allowing the bpf() syscall is safe as its usage is still gated by
selinux and regular apps are not allowed to use it.
Bug: 202785178
Test: m
Signed-off-by: Alessio Balsini <balsini@google.com>
Change-Id: I5887e8d22906c386307e54d3131c679fee0d9f26
We could remove this line, but it seems reasonable to leave it in for
clarification/safety, especially if it's moved after the common success
case?
Test: treehugger
Change-Id: I5f7e0da8397f80018e6d55321b26371790087f5c
Mbstowcs and wcstombs cannot get correct return value when called in the environment below api 21, and need to raise the API level to solve the problem.
Test: None
fix bug 1108 https://github.com/android/ndk/issues/1108
Change-Id: Iabcf1bff0be087288646687732ef68870630b48a
"nonplat" was renamed to "vendor" in Android Pie, but was retained
here for Treble compatibility.
We're now outside of the compatbility window for these devices so
it can safely be removed.
Test: build boot cuttlefish device. adb remount, modify
/system/etc/selinux/plat_sepolicy_and_mapping.sha256 to force
on-device policy compilation. reboot. Verify that device boots
without new selinux denials.
Change-Id: I663a524670120ee19dfe785aa5f89b3981bdd378
This came up with POSIX recently. Doesn't seem like it matters since
everyone's had this wrong for 40 years, but "meh" --- it's a trivial
fix, and it's strictly correct even if nobody needs this, so let's just
do it...
(Geoff Clare pointed out that my app compat concern "what if someone's
relying on this bug to pass flags to the shell?" isn't relevant because
while you can indeed do that, you then can't pass a command!)
Bug: https://austingroupbugs.net/view.php?id=1440
Test: treehugger
Change-Id: I64f6440da55e2dc29d0136ee62007197d2f00d46
Clang cannot build ifunc with LTO. This is a KI: https://bugs.llvm.org/show_bug.cgi?id=46488
Move the LTO: never down to libc itself, so that we can have LTO for the
rest of linker.
Test: m GLOBAL_THINLTO=true linker
Change-Id: I483fc3944e340638a664fb390279e211c2ae224b
The native bridge libc.so is overridden by
//frameworks/libs/native_bridge_support/libc:libc, mark it
installable: false to avoid a collision in the install rules.
Allows removing BUILD_BROKEN_DUP_RULES from cuttlefish builds.
Relands I5379aa9595a714efdbe1ddc1ff4f65bb45fc67e8 with a fix to
only apply to the shared variant.
Bug: 204136549
Test: m checkbuild
Change-Id: I84abb577e3bb924d39a369670d0b2dbfac45bbc4
The native bridge libc.so is overridden by
//frameworks/libs/native_bridge_support/libc:libc, mark it
installable: false to avoid a collision in the install rules.
Allows removing BUILD_BROKEN_DUP_RULES from cuttlefish builds.
Bug: 204136549
Test: m checkbuild
Change-Id: I5379aa9595a714efdbe1ddc1ff4f65bb45fc67e8
This saves a couple of syscalls in the common case, and also lets static
binaries run in a chroot without /dev/null as long as
stdin/stdout/stderr are actually connected to something (which the
toybox maintainer tried to do).
Test: manual with strace
Change-Id: Ic9a28896a07304a3bd428acfd9ddca9d22015f6e
They're in glibc, though not in musl.
Also add basic doc comments to the whole of <sys/uio.h>.
Bug: http://b/203002492
Test: treehugger
Change-Id: Ic607f7f349e5b7c9bf66c25b7bd68f827da530d6
In the following scenario:
* Heapprofd wants to profile a process.
* The process receives the heapprofd signal, so it sets up the ephemeral
hooks.
* The process does not perform any allocation, so the proper heapprofd
hook is never installed.
* Heapprofd terminates.
* Now heapprofd wants to start a new profiling session.
* The process receives the heapprofd signal (again).
In the signal handler, no action is needed at this point. The ephemeral
hooks are already setup, so, at the next malloc, the proper heapprofd
hooks will be installed.
Before this commit, the code logged an error message, but still worked
correctly.
This commit basically just skips the error_log below.
Example of the error message that is now suppressed:
```
process: heapprofd: failed to transition kInitialState ->
kInstallingEphemeralHook. current state (possible race): 2
```
Tested by:
* Running a process that calls malloc on input from stdin.
* (Optional, tested both cases) Enable GWP-Asan by calling
`android_mallopt(M_INITIALIZE_GWP_ASAN, ...`. The call will return
success.
* Attaching heapprofd:
```
external/perfetto/tools/heap_profile -i 1 -p `adb shell pidof <...>`
```
* Detaching heapprofd (CTRL-C). The trace will be empty.
* (If not enabled before) Enabling GWP-Asan. The call will fail (because
GWP-Asan detects heapprofd hooks).
* Reattaching heapprofd.
* Triggering some malloc()s in the process. The error log from above
will not appear in `adb logcat`.
* Detaching heapprofd (CTRL-C). The trace will NOT be empty.
Bug: 192258849
Change-Id: I01699b10ecd19e52e1e77f83fcca955ebd885942
