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
It's possible for the main thread to leave the RunTimedTest
function before the waiting thread has had a chance to call e.g.
pthread_cond_timedwait(). In this case, pthread_cond_timedwait()
will access the local variable ts after its lifetime has ended. Fix
the bug by making ts a field of pthread_CondWakeupTest instead. The
lifetime of pthread_CondWakeupTest is tied to that of the waiting
thread via the pthread_join() call.
Found with HWASan + uaccess logging.
Change-Id: Iefe8deb30a367dc518013d741c425b041596b0d3
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
Bug: http://b/150809112
This is a new upstream library that exports both the clang and LLVM C++
symbols and can replace libLLVM and (android-toolchain-only)
libclang_cxx.so.
Test: Build and run versioner
Change-Id: Ib711c29f478e00e39f26dd09917618b349f0c786
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
