The apex hash tree is automatically generated at compile time for
apexes in apexd-bootstrap, so there's no need to explicitly specify
anything here.
Bug: b/203820392, b/198361718
Test: presubmit
Change-Id: I5ff0363fde701e7fe4e3ed8ab274c6a57852828c
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
I don't think the old benchmarks made any sense; going through all the
characters might have made sense as a unit test, but I'm not sure how
actionable they were for realistic cases. In particular, "all ASCII" is
a common special case that's worth measuring separately. I'm still not
hugely convinced, but at least separating the "ASCII" and "wide" paths
is an improvement. I can't think of a case where we did optimization
work on this kind of code without considering those two paths
separately.
I've added to the single-character benchmarks by splitting out the
separate cases instead --- one benchmark each for single-byte up to
4-byte characters.
Bug: http://b/206523398
Test: treehugger
Change-Id: I58cbfedb4b497a55580857eff307a024938cf006
LLD supports `-z global`, unlike ld.gold, which this was previously a
workaround for.
Test: mm in test dir
Change-Id: I1f621c329accfb31912a19544e34447aff0dfa28
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
Explicitly test an invalid 5-byte UTF-8 sequence with mbrtoc16(3); the
fact that we weren't testing this was shown by coverage data.
Merge the surrogate pair tests in with their fewer-byte siblings to make
it clearer to a human reader that we've covered both cases.
Clear errno to make assertions about errno more convincing.
Test: treehugger
Change-Id: I485a48cc141f3e52058e2138326f3134d41b2243
"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
This is a KI: https://bugs.llvm.org/show_bug.cgi?id=46488
Bug: 203737712
Test: m GLOBAL_THINLTO=true bionic-unit-tests-static
Change-Id: I950a85f9676136299fc994a800d32e20bf12a8dd
These docs refer to the old coverage workflow from the Android.mk
build.
AFAIK there's no way to get coverage for the host tests, so that part
was removed.
Test: followed the docs, got coverage data
Bug: None
Change-Id: Ibef5ae2d354296a77b752d3b7c9c48cf7a34ef98
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
* -Wstatic-in-inline found in
libm/upstream-freebsd/lib/msun/src/s_lround.c
Test: mm in bionic/tests
Bug: 201432564
Bug: 202752322
Change-Id: I4d506fa539ab0de939d85924a5fd9a61644e4fb0
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
