The NDK no longer includes gold, so static binaries built by the NDK no
longer need to support gold.
Test: bionic static unit tests
Change-Id: Idddcb9eb18921acfc1ae2a3c755592a5ab30290a
The android_unsafe_frame_pointer_chase keeps going even when a
frame is 0. Modify the unwind to stop when this case is found.
I found this while running the GwpAsanCrasherTest.run_gwp_asan_test
from debuggerd_test and printing the tombstone created. The
deallocated by and allocated by stack traces always ended in 0 frame.
After fixing this, the last 0 frame is no longer present.
Test: Ran the debuggerd test and printed the tombstone on a raven
Test: verifying that the last frame is non-zero.
Test: Ran the bionic unit tests.
Change-Id: I8d64679277abcf5f237e6759051db11ffaa34c2f
The bionic benchmarks set the decay time in various ways, but
don't necessarily restore it properly. Add a new method for
getting the current decay time and then a way to restore it.
Right now the assumption is that the decay time defaults to zero,
but in the near future that assumption might be incorrect. Therefore
using this method will future proof the code.
Bug: 302212507
Test: Unit tests pass for both static and dynamic executables.
Test: Ran bionic benchmarks that were modified.
Change-Id: Ia77ff9ffee3081c5c1c02cb4309880f33b284e82
The zygote cannot have visiblity to LIBC_PLATFORM methods. Therefore,
move __system_properties_reload to LIBC, and rename it
__system_properties_zygote_reload, and indicate in comments that it
should not be used by non-zygote apps
Bug: 291814949
Test: atest CtsBionicRootTestCases
Change-Id: Iee8fa0c76b740543c05a433393f2f4bef36d6d3d
Create a second set of system properties, that can be overlaid over the
real ones if necessary, for appcompat purposes.
Bug: 291814949
Ignore-AOSP-First: Aosp -> internal merge conflict
Test: manual, treehugger, system_properties_test
Change-Id: I541d3658cab7753c16970957c6ab4fc8bd68d8f3
Merged-In: I884a78b67679c1f0b90a6c0159b17ab007f8cc60
Adds support for the dynamic entries to specify MTE enablement. This is
now the preferred way for dynamically linked executables to specify to
the loader what mode MTE should be in, and whether stack MTE should be
enabled. In future, this is also needed for MTE globals support.
Leave the existing ELF note parsing as a backup option because dynamic
entries are not supported for fully static executables, and there's
still a bunch of glue sitting around in the build system and tests that
explicitly include the note. When -fsanitize=memtag* is specified, lld
will create the note implicitly (along with the new dynamic entries),
but at some point once we've cleaned up all the old references to the
note, we can remove the notegen from lld.
Bug: N/A
Test: atest bionic-unit-tests CtsBionicTestCases --test-filter=*Memtag*
Test: Build/boot the device under _fullmte.
Change-Id: I954b7e78afa5ff4274a3948b968cfad8eba94d88
The first app developer (we know of) that hit this didn't understand
what it was trying to tell them.
Before:
FORTIFY: fcntl(F_SETFD) passed non-FD_CLOEXEC flag: 0x801
After:
FORTIFY: fcntl(F_SETFD) only supports FD_CLOEXEC but was passed 0x801
Bug: https://issuetracker.google.com/304348746
Test: treehugger
Change-Id: I8522e851d8f74c91152ebae68b083b5272d49255
The NDK only supports API 21 and later, so we don't need to worry
about older API levels any more.
All the functions in this file are trivial, being but a single
instruction on most architectures. For that reason, we inline them by
default. (We continue to also provide actual symbols for any caller
that needs them --- in particular existing binaries!)
Also inline all the _l() variants too. No-one should be using them,
but since we're already using trickery to only implement the non-_l()
variants once, we may as well use the same trick for both.
Test: treehugger
Change-Id: I17637c49dd14be9e5ecb8246e72e8acc662739f1
strerrordesc_np() isn't very useful (being just another name for
strerror()), but strerrorname_np() lets you get "ENOSYS" for ENOSYS,
which will make some of our test assertion messages clearer when we
switch over from strerror().
This also adds `%#m` formatting to all the relevant functions.
Test: treehugger
Change-Id: Icfe07a39a307d591c3f4f2a09d008dc021643062
Currently, we use sentinels (starting with -1 and ending with 0) in
preinit_array/init_array/fini_array in executables. But after using LTO,
the sentinels can be reordered by LLD and no longer work. So make below
changes to not rely on them:
1. In crtbegin.c, use symbols (like __init_array_start) inserted by the
linker.
2. Add array_count fields in structors_array_t.
3. In static libc, use array_count fields to decide array lengths.
4. To make new dynamic executables work with old libc.so, create a fake
fini_array with sentinels, and pass it to __libc_init. The fake
fini_array contains a function to call functions in real fini_array.
5. To make old dynamic executables work with new libc.so, libc.so
still uses sentinels to decide the length of fini_array.
Bug: 295944813
Bug: https://github.com/android/ndk/issues/1461
Test: run bionic-unit-tests-static
Test: test static executables manually
Test: boot cf_gwear_x86-trunk_staging-userdebug
Change-Id: I1ce31f07bcfe0e99b4237984898a8fc9e98ff426
When used in an ifunc resolver, errno@plt won't be available. This is
the API the rivos folks contributing to glibc are leaning towards, for
the same reason. Hit by the berberis folks because they don't implement
the syscall so they were trying to set errno to ENOSYS.
Tested by looking at the generated assembler, and also disabling the
vdso (since on actual systems, this will go via the vdso).
Test: treehugger
Change-Id: Ie2779110f141f20efe97cb892fbdefd808b5339b
musl already added tcgetwinsize() and tcsetwinsize(), but I didn't
notice.
Trivial single-line inlines added to a header that's already written
that way.
Test: treehugger
Change-Id: Iac95ea6a89f3872025c512f7e61987b81d0aafa7
This is a bit disappointing. I'd not implemented this in the past
because it wasn't available on all platforms, and -- although the
riscv64 implementation was just a cool optimization -- I thought that
the /sys stuff was actually portable, until I ran it on arm64 hardware.
So here we have getauxval() for riscv64, /sys for x86-64, and our best
guess based on ctr_el0 for arm64.
Bug: http://b/294034962
Test: ran tests on the host, an arm64 device, and riscv64 host and qemu
Change-Id: I420b69b976d30668d4d2ac548c4229e2a4eafb20
I've also added doc comments for everything in <sys/epoll.h>.
I've also broken up the old "smoke" test (which was taking 2s on my
riscv64 qemu) to keep the total runtime for all the tests down to 200ms.
Test: treehugger
Change-Id: Icd939af51886fdf21432653a07373c1a0f26e422
Android V will support page size agnostic targets. The bionic macro
PAGE_SIZE won't be defined for the agnostic targets.
The PAGE_SIZE macro will be replaced by max_page_size() instead.
- For not agnostic builds, max_page_size() will be replaced by 4096.
- For agnostic builds, it will be replaced by 16384
Bug: 296907948
Test: source build/envsetup.sh
lunch aosp_cf_arm64_phone_pgagnostic
m
source build/envsetup.sh
aosp_cf_x86_64_phone-userdebug
m
Change-Id: I81731a2ec59decd19ab9fd714d4f2ac20df873b7
Use the real page size from getauxval() for memtag stack
MTE protection.
Bug: 296275298
Test: atest -c bionic-unit-tests
Change-Id: I1711291b918b09e5464f1d15358dd1ff7fa2f371
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Talking futher to the person doing the glibc risc-v ifunc work, they
clarified that glibc _is_ passing hwcap as the first argument, and the
null pointer is actually the second argument.
https://sourceware.org/pipermail/libc-alpha/2023-August/150967.html
So since our whole purpose here was source compatibility, let's do what
they're actually doing, and let's add some tests. I've also added a test
that __riscv_hwprobe() works from an ifunc resolver because that's one
place where it might well be used. That said, one other thing that came
out of the discussion is that I actually went away and looked at a
sample of top apps to see how many are using ifuncs currently. The
result? Zero. So although this _might_ be interesting long term
(especially if clang gets riscv64 FMV), I think we've done more than we
need to with riscv64 ifuncs for now!
Test: ran locally, both dynamic and static tests
Change-Id: Ie2044d9f4e47c32c00ad381f045c537f4df38b08
Under some circumstances, it's possible to fail the enable allocation
limit android_mallopt call. Increase the total allowed time for the
function to complete.
In addition, if the enable fails, allow another limit call to succeed
in the future.
Finally, change the limit test to use _exit instead of exit.
Bug: 291672185
Test: Ran limit test thousands of times.
Test: Forced the limit to fail and verified the second call passes.
Change-Id: I0948e6fd97231a7538b9b82b76f0a207386681b1
The magic numbers that C defines are obnoxious. We had partial
definitions for these internally. Add the missing one and move them to
a public header for anyone else that may want to use them.
Bug: None
Test: None
Change-Id: Ia6b8cff4310bcccb23078c52216528db668ac966
We've had these backward all this time. The relevant quote is in a
code comment in the implementation, but the first call after
completely decoding a code point that requires a surrogate pair should
return the number of bytes decoded by the most recent call, and the
second call should return -3 (if only C had given those some named
constants that might have been more obviously wrong).
Bug: https://issuetracker.google.com/289419882
Test: Fixed the test, tests run against glibc and musl to confirm
Change-Id: Idabf01075b1cad35b604ede8d676d6f0b1dc91e6
glibc maintainer Florian Weimer pointed out that glibc passes a null first
argument to riscv64 ifunc resolvers. While not super useful right now,
that does make it much easier to switch to providing arguments in future,
such as my favorite idea of passing a default set of hwprobe key/value
pairs, along with a count of how many pairs.
Test: treehugger
Change-Id: Ibe2148dc28aa6ad230e6324b6d725fe472b7ef33
Also de-pessimize time(), where the vdso entrypoint only exists on
x86/x86-64 anyway.
Bug: https://github.com/google/android-riscv64/issues/8
Test: strace
Change-Id: I14cb2a3130b6ff88d06d43ea13d3a825a26de290
While looking at the disassembly for the epoll stuff I noticed that this
expands to quite a lot of code that the compiler can't optimize out for
LP64 (because it doesn't know that the "copy the argument into a local
and then use the local" bit isn't important).
There are two obvious options here. Something like this:
```
int signalfd64(int fd, const sigset64_t* mask, int flags) {
return __signalfd4(fd, mask, sizeof(*mask), flags);
}
int signalfd(int fd, const sigset_t* mask, int flags) {
#if defined(__LP64__)
return signalfd64(fd, mask, flags);
#else
SigSetConverter set = {.sigset = *mask};
return signalfd64(fd, &set.sigset64, flags);
#endif
}
```
Or something like this:
```
int signalfd64(int fd, const sigset64_t* mask, int flags) {
return __signalfd4(fd, mask, sizeof(*mask), flags);
}
#if defined(__LP64__)
__strong_alias(signalfd, signalfd64);
#else
int signalfd(int fd, const sigset_t* mask, int flags) {
SigSetConverter set = {};
set.sigset = *mask;
return signalfd64(fd, &set.sigset64, flags);
}
#endif
```
The former is slightly more verbose, but seems a bit more obvious, so I
initially went with that. (The former is more verbose in the generated
code too, given that the latter expands to _no_ code, just another symbol
pointing to the same code address.)
Having done that, I realized that slight changes to the interface would
let clang optimize away most/all of the overhead for LP64 with the only
preprocessor hackery being in SigSetConverter itself.
I also pulled out the legacy bsd `int` conversions since they're only
used in two (secret!) functions, so it's clearer to just have a separate
union for them. While doing so, I suppressed those functions for
riscv64, since there's no reason to keep carrying that mistake forward.
posix_spawn() is another simple case that doesn't actually benefit from
SigSetConverter, so I've given that its own anonymous union too.
Test: treehugger
Change-Id: Iaf67486da40d40fc53ec69717c3492ab7ab81ad6
When I added %m to async_safe_* too, we never followed up and cleaned up
callers.
Test: treehugger
Change-Id: If81943c4c45de49f0fb4bc29cfbd3fc53d4a47fe
Failure to mark shadow stack page as writable will result in a SEGV
fault later when a function tries to save return addresses to shadow
stack. The engineer looking at the crash report would be very confused
because the program crashes at very beginning of an innocent looking
function. For ease of debugging, check for shadow stack errors early.
Test: th
Bug: 279808236
Bug: 253652966
Change-Id: Id2da68fa984b5dfb1846ed14aa7ededee7f2508f
This new mallopt cause statistics of the allocator to be printed in
the log.
Add a stats print for jemalloc.
This is designed to be used as part of a dumpsys meminfo --XXXX
option so that it's easier to get information about apps that
have an unusual memory footprint.
Test: Unit tests pass.
Test: Ran on a device using jemalloc and verified log data.
Test: Ran on a device using scudo and verified log data.
Change-Id: I6fa44ce619c064b2596fbbb478c231994af94f4c
* Rationale
The question often comes up of how to use multiple time zones in C code.
If you're single-threaded, you can just use setenv() to manipulate $TZ.
toybox does this, for example. But that's not thread-safe in two
distinct ways: firstly, getenv() is not thread-safe with respect to
modifications to the environment (and between the way putenv() is
specified and the existence of environ, it's not obvious how to fully
fix that), and secondly the _caller_ needs to ensure that no other
threads are using tzset() or any function that behaves "as if" tzset()
was called (which is neither easy to determine nor easy to ensure).
This isn't a bigger problem because most of the time the right answer
is to stop pretending that libc is at all suitable for any i18n, and
switch to icu4c instead. (The NDK icu4c headers do not include ucal_*,
so this is not a realistic option for most applications.)
But what if you're somewhere in between? Like the rust chrono library,
for example? What then?
Currently their "least worst" option is to reinvent the entire wheel and
read our tzdata files. Which isn't a great solution for anyone, for
obvious maintainability reasons.
So it's probably time we broke the catch-22 here and joined NetBSD in
offering a less broken API than standard C has for the last 40 years.
Sure, any would-be caller will have to have a separate "is this
Android?" and even "is this API level >= 35?" path, but that will fix
itself sometime in the 2030s when developers can just assume "yes, it
is", whereas if we keep putting off exposing anything, this problem
never gets solved.
(No-one's bothered to try to implement the std::chrono::time_zone
functionality in libc++ yet, but they'll face a similar problem if/when
they do.)
* Implementation
The good news is that tzcode already implements these functions, so
there's relatively little here.
I've chosen not to expose `struct state` because `struct __timezone_t`
makes for clearer error messages, given that compiler diagnostics will
show the underlying type name (`struct __timezone_t*`) rather than the
typedef name (`timezone_t`) that's used in calling code.
I've moved us over to FreeBSD's wcsftime() rather than keep the OpenBSD
one building --- I've long wanted to only have one implementation here,
and FreeBSD is already doing the "convert back and forth, calling the
non-wide function in the middle" dance that I'd hoped to get round to
doing myself someday. This should mean that our strftime() and
wcsftime() behaviors can't easily diverge in future, plus macOS/iOS are
mostly FreeBSD, so any bugs will likely be interoperable with the other
major mobile operating system, so there's something nice for everyone
there!
The FreeBSD wcsftime() implementation includes a wcsftime_l()
implementation, so that's one stub we can remove. The flip side of that
is that it uses mbsrtowcs_l() and wcsrtombs_l() which we didn't
previously have. So expose those as aliases of mbsrtowcs() and
wcsrtombs().
Bug: https://github.com/chronotope/chrono/issues/499
Test: treehugger
Change-Id: Iee1b9d763ead15eef3d2c33666b3403b68940c3c
To enable experiments with non-4KiB page sizes, introduce
an inline page_size() function that will either return the runtime
page size (if PAGE_SIZE is not 4096) or a constant 4096 (elsewhere).
This should ensure that there are no changes to the generated code on
unaffected platforms.
Test: source build/envsetup.sh
lunch aosp_cf_arm64_16k_phone-userdebug
m -j32 installclean
m -j32
Test: launch_cvd \
-kernel_path /path/to/out/android14-5.15/dist/Image \
-initramfs_path /path/to/out/android14-5.15/dist/initramfs.img \
-userdata_format=ext4
Bug: 277272383
Bug: 230790254
Change-Id: Ic0ed98b67f7c6b845804b90a4e16649f2fc94028
Discussion of this during my recent minor cleanup convinced me that we
should just remove __RENAME_LDBL. There's no obvious benefit to being
able to build something for 32-bit if you can't build the same code for
64-bit, given that most new hardware (and entire verticals such as Auto)
are 64-bit-only, and the Play Store requires any app with 32-bit code to
also ship 64-bit code.
Test: treehugger
Change-Id: I1c5503b968ca66925d7bd125bd3630c41ec1bfd0
