This is already covered by the existing test by virtue of being used for
all threads.
Bug: http://b/168258494
Test: treehugger
Change-Id: I5c872fd7f30a4c79de1d70e7702f4b12d4e94cd3
An upcoming change to Scudo will change how we use the TLS slot
in tsd_shared.h, which will be a little easier to deal with if
we can remove the code path that calls pthread_getspecific and
pthread_setspecific. The only known user of this code path is Fuchsia.
We can't eliminate this code path by making Fuchsia use ELF TLS
because although Fuchsia supports ELF TLS, it is not supported within
libc itself. To address this, Roland McGrath on the Fuchsia team has
proposed that Scudo will optionally call a platform-provided function
to access a TLS slot reserved for Scudo. Android also has a reserved
TLS slot, but the code that accesses the TLS slot lives in Scudo.
We can eliminate some complexity and duplicated code by having Android
implement the same mechanism that was proposed for Fuchsia, which is
what this change does. A separate change to Scudo will make use of it.
Bug: 163630045
Change-Id: I4678105c9c47a23feb5a5e80a314416de4556d9c
Except they are the same on arm32/arm64, so we hadn't really noticed. x86
and x86-64 are quite different though, presumably by historical accident.
Fix the definitions and add some static asserts.
Bug: https://github.com/android/ndk/issues/1347
Test: treehugger
Change-Id: Ic27b172066cf3443749463b9b73c912d204f9516
This benchmarks mapping property prefixes to property contexts with
two algorithms: the 'Legacy' method used before Android P and the
'Trie' used afterwards (the code in this directory).
It uses input mappings from both Oreo and the latest in AOSP ('S').
Note that there is nearly a 10x increase in the number of mappings in
S as there was in Oreo, which was predicted when the trie was
designed.
Results on cuttlefish:
-----------------------------------------------------------
Benchmark Time CPU Iterations
-----------------------------------------------------------
LegacyLookupOreo 683576 ns 673538 ns 1060
LegacyLookupS 5683109 ns 5596982 ns 124
TrieLookupOreo 299851 ns 295696 ns 2378
TrieLookupS 584831 ns 576801 ns 1204
The results show that the legacy look up uses 8.3x more CPU time to
handle the number of mappings added through S, whereas the Trie lookup
uses less than 2x more CPU time, showing that the trie scales better
with added mappings.
Test: run this benchmark
Change-Id: I35c3aa4429f049e327a891f9cbe1901d8855d7ba
I made toybox use strptime %Z recently (so that it can parse the default
POSIX date(1) output), forgetting that bionic's strptime(3) doesn't
support %Z. Neither does glibc, for that matter; the toybox change works
on glibc effectively by accident --- glibc just ignores the next word
when parsing %Z and assumes that the current time zone ($TZ) is
appropriate. Which it is for the only obvious use case of "round trip
date(1) output".
The related %z is potentially quite a bit more useful in general (parsing
any valid RFC822 time zone), though sadly not useful for the toybox case
that prompted.
Every time I touch this file I promise that I'll actually get us back in
sync with upstream, and every time I fail to get round to it. Maybe
2020 or 2021 will finally be the year...
Also add corresponding tests.
Bug: https://b/167455975
Test: treehugger
Change-Id: I13a7fb7e3ad01ae855750b9314d2eec661fe034f
Some global static variables are only used within a single function,
so moving them inside the function which requires them. This also
ensures those static variables of class types are initialized before
they are being used.
For example, this is needed for CachedProperty(), as some of the
member method, e.g., CachedProperty().Get(), might be invoked,
e.g., in __libc_preinit(), before the constructor is invoked.
This happens after we added property trace points in commit
Id2b93acb2ce02b308c0e4889f836159151af3b46.
For g_lock, we don't move them because it can be initialized by setting
its memory to 0. And it's used in two functions.
https://android.googlesource.com/platform/bionic/+/refs/heads/master/libc/private/bionic_lock.h
Bug: 147275573
Test: atest CtsBionicTestCases
Test: adb shell perfetto -o /data/misc/perfetto-traces/test_trace -t 10s bionic sysprop
Change-Id: I99565ce2442d34f33830778915c737eed834f8b3
Like with close, socket is no longer a simple syscall, so we can get
recursive calls that deadlock.
Bug: http://b/165206592
Test: bionic-unit-tests on cuttlefish
Test: treehugger
Change-Id: I2ba77d733d1ebf08a91afd6ca179e7ae6ae3866e
bionic/libm/x86_64/s_log1p.S:809:2: error: changed section type for .note.GNU-stack, expected: 0x1
.section .note.GNU-stack, ""
^
These assembly sources are missing @progbits to set the section flags
correctly. Without it, they end up denoting a different section type. By
adding the @progbits explicitly, we see the same section flags with
readelf.
[ 4] .note.GNU-stack PROGBITS 0000000000000000 000593 000000 00 0 0 1
Bug: http://b/155835175
Test: m for aosp_x86_64
Change-Id: Ifff35d35f5f9ded5938e88677b18805809820e9f
Introducing a new systrace tag, TRACE_TAG_SYSPROP, for use with
system property.
For property set, the tracing is added in __system_property_set() instead of
__system_property_update() / __system_property_add() so we can record
control properties like ctl.*, sys.powerctl.*, etc.., which won't be
updated via the latter two functions.
Bug: 147275573
Test: atest CtsBionicTestCases
Test: adb shell perfetto -o /data/misc/perfetto-traces/test_trace -t 10s bionic
Test: adb shell perfetto -o /data/misc/perfetto-traces/test_trace -t 10s sysprop
Test: adb shell /data/benchmarktest64/bionic-benchmarks/bionic-benchmarks \
--benchmark_filter=BM_property --bionic_cpu=4, then compares the results
of property benchmarks before and after the change, didn't see
significant difference.
Change-Id: Id2b93acb2ce02b308c0e4889f836159151af3b46
Merged-In: Id2b93acb2ce02b308c0e4889f836159151af3b46
(cherry picked from commit 26970c3493)
bionic/tests/fortify_test.cpp:207:31: error: format specifies type 'char *' but the argument has type 'void *' [-Werror,-Wformat]
ASSERT_FORTIFY(printf("%s", memchr(myfoo.a, 'a', asize)));
~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~
Bug: http://b/155835175
Test: atest for bionic
Change-Id: I0fa4e63deadffb7391e66ab834ff11e4f1d6dba6
We can't have HWASAN enabled in these resolvers because they
may be called before HWASAN is initialized.
We were previously getting away with HWASAN being enabled on these
functions because ANDROID_EXPERIMENTAL_MTE was not defined, which
let the compiler simplify away any HWASAN instrumentation in the
resolvers. But with this build flag enabled (which is currently the
case in FVP, and eventually everywhere once the MTE kernel patches
land) the resolvers end up containing an HWASAN instrumented load of
the _hwcap2 field.
Bug: 135772972
Change-Id: Iac79d02ddc81630c955e107eb7f78389aeb33879
Mostly from extra test cases, but also:
* Move the fgets size < 0 assertion into fgets.
* Use ELF aliases for strtoq/strtouq rather than duplicating code.
* Don't check uname() succeeded, since it can't fail.
Test: treehugger
Change-Id: I2e6b3b88b0a3eb16bd68be68b9bc9f40d8043291
