We're still copy & pasting this workaround about, but the bug was supposedly fixed years ago!
Bug: http://b/34945607
Bug: http://b/33942619
Bug: http://b/34195559
Change-Id: Icf3d184d2ddb447dff7dacccea1dc903da816505
It's usually more helpful to see all the output so far.
If we're worried about fflush() failing because of the state we're in, we shouldn't be using stdio at all!
If this _does_ become a problem, we should probably switch to using the internal functions: `__assert2` for bionic, `__assert_fail` for musl/glibc, and `__assert_rtn` for macOS.
Unfortunately although `__assert2` and `__assert_fail` take the same arguments, they're in a different order, so we can't simply add a symbol alias to make that difference go away, and it's not clear that there's enough value to adding an otherwise unused symbol.
Change-Id: I653183737ab6368890bbd9d0e2f37fc5cb2e1dec
This avoids a diagnostic on arm32/arm64 when running ldd on a shared
library with a PT_TLS segment:
executable's TLS segment is underaligned: alignment is 8, needs to be at least 64 for ARM64 Bionic
Bug: http://b/328822319
Test: ldd /system/lib64/libc.so
Change-Id: Idb061b980333ba3b5b3f44b52becf041d76ea0b7
The loader doesn't currently support using TLS within itself.
Previously, if a TLS segment was accidentally linked into the loader,
then the loader's `soinfo_tls* tls_` field would be initialized with a
valid TlsSegment, but the loader soinfo wouldn't be registered with
linker_tls.cpp, so the module ID would be 0. (The first valid module ID
is 1.)
The result was architecture-dependent. On x86, everything worked until
the first TLS access, which segfaulted. On arm64, relocating TLSDESC
hit a CHECK() failure on the invalid module ID.
Make the loader more robust:
* Abort in the loader if it detects that it has a TLS segment.
* For R_GENERIC_TLS_DTPMOD, verify that a module ID is valid before
writing it.
Bug: none
Test: manually add a thread_local variable to the loader
Test: bionic-unit-tests
Change-Id: I93c17ca65df4af2d46288957a0e483b0e2b13862
Change the AT_All_XXX to AT_ALL_XXX.
Change the name of the from_prot and to_prot parameters to be more
descriptive.
Add a few extra large page sizes. Without this, it jumps from a
relatively small size to an extreme large size and nothing in
between.
Clang-format modified the args_shorthand initialization.
Test: Ran benchmarks on device.
Change-Id: I5105788cbf05793fcb4d86c26037ec435635631e
Only zero the partial page at the end of the segment. There may be
entire pages beyond first page boundary after the segment -- due to
segment padding (VMA extension); but these are not expected to be
touched (faulted).
Do not attempt to zero the extended region past the first partial page,
since doing so may:
1) Result in a SIGBUS, as the region is not backed by the underlying
file.
2) Break the COW backing, faulting in new anon pages for a region
that will not be used.
Bug: 327600007
Bug: 328797737
Test: Dexcom G7 app
Test: atest -c linker-unit-tests
Test: bootup/idle/system-processes-memory-direct
Change-Id: Ib76b022f94bfc4a4b7eaca2c155af81478741b91
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Vendor modules do not follow bionic versioning but define their own
versioning for LLNDK. Ignore the __INTRODUCED_IN annotation for
vendor modules.
Bug: 302113279
Test: build trunk-staging and next configurations
Change-Id: I04646b524d17f7ae47f0f96cb98f221f3e821629
We cannot use a WriteProtected because we are accessing it in a
multithreaded context.
Test: atest memtag_stack_dlopen_test w/ MTE
Test: atest bionic-unit-tests w/ MTE
Test: atest bionic-unit-tests on _fullmte
Bug: 328256432
Change-Id: I39faa75f97fd5b3fb755a46e88346c17c0e9a8e2
Specific parameters were chosen based on the frequency of their use in
Android.
Bug: 327496587
Test: local build and run
Change-Id: Iec225109f62e1e9cde133863d3cee8103172a6c8
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Apparently we hadn't looked at the disassembly of these benchmarks since
implementing the various <ctype.h> functions inline, because they've all
been optimized away to literal loads of 0 or 1.
Obviously, this is not helpful when trying to judge further
optimizations.
Test: objdump and ran the benchmarks (on both arm64 and arm32)
Change-Id: Id66c4f7f4c92d9eee8937d31546158eda62ef3ba
We would get the SP inside of memtag_handle_longjmp, which could prevent
us from detecting the case where a longjmp is going into a function that
had already returned. This changes makes the behaviour more predictable.
Change-Id: I75bf931c8f4129a2f38001156b7bbe0b54a726ee
This file no longer covers only mmap benchmarking, but also additional
memory related syscalls. Adjusting the name of this file to reflect the
broader utilization.
Bug: 327496587
Test: local build and run
Change-Id: I988e949589f9731fb1d85f489cd46ae64bf0a74c
Signed-off-by: Carlos Galo <carlosgalo@google.com>