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
Both glibc/musl's and Apple's <string.h> drags in <strings.h> in most
cases. So do the BSDs. Given so much historic precedent (often accompanied
by comments saying "POSIX made us move this stuff out into another
file, but we don't want to break existing code [from the 1980s]"!), plus
the fact that someone hit this in practice, trying to build one of the
linux selftests against bionic, let's change bionic over too...
Bug: http://b/310035365
Test: treehugger
Change-Id: I8f13d82fe3d3df71a656641a725410acdfd97465
Right now, the unwinder doesn't support compressed sections, so unwinds
through the 32 bit libc.so don't work. It will be supported very soon,
but even then, it will be slower to use, so make sure the debug_frame
is not compressed at all.
Bug: 309857311
Test: 32 bit debuggerd unit tests pass.
Test: 32 bit unwind unit tests pass.
Change-Id: Ic8bec1d275c629ec43051bbe912014f281450eda
There are a lot of bugs about this over the years, too many to
reference here. Though, I referenced b/176065420 to understand
exactly why it's problematic and what the future direction may
be.
Fixes: 307859642
Test: N/A
Change-Id: Ida31fe622309a7f9b2cd55e5bbb3569fc5aded0e
This came up in a man-pages discussion. I've left the ones that take an
integer to say what _units_ they sleep in, but the ones that take a
struct seem clearest if they just say "duration".
Test: treehugger
Change-Id: I13e39855a9d2c49e1653ec2263cb09c9f239254d
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
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-6.6
Test: Builds and bionic unit tests pass on raven.
Test: Able to log in to an Android GO 32 bit device.
Change-Id: Ib5ff5a23f382721d98d1e428a295c6794b190d8d
Investigation revealed that the vector instructions in the assembly
implementation of memcmp seem to be putting QEMU into a bad state. This
code sometimes results in a SIGILL.
Temporarily disable the vector instructions for just this function.
Bug: 306514350
Test: Verified boot on AOSP CF image.
Change-Id: I184762354092b4b500c78a29a10db18cef0dab90
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
Rather than do the work to fix the ODR violations while preserving non-V,
let's just remove the non-V code. Android will require V anyway, and
anyone trying to work on a non-V system in the meantime already needs
a bunch of patches to the build system and ART, so one more shouldn't
hurt too much.
Test: treehugger
Change-Id: Iab43d8a80d99a4d045b0008dbea4e7e8696d1167
We were copying the data fine, but the return value was one vector
length too far (but also not taking into account the actual number of
bytes in the last transfer).
Also move the stpcpy() tests to EXPECT_EQ() so we get all the details
of the failure at once.
Test: treehugger
Change-Id: I76bf02c8a31f40722acb7c9fd8e301d50e405bf8
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
Add test for aosp/2792161
Bug: 297317502
Test: cpp.py
Change-Id: I2eadd3b9371ec2f8b8c24107888cad5e3ae26f60
Signed-off-by: Edward Liaw <edliaw@google.com>
replaceTokens was only replacing tokens for cpp name clashes in the
macro body. This change will also replace tokens in the arguments.
Bug: 297317502
Test: bionic/libc/kernel/tools/update_all.py
Change-Id: I102d000a8a4cea507b00c867df2a16106d8aed89
Signed-off-by: Edward Liaw <edliaw@google.com>
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
We were keeping the macros that call this function, but not the function
itself. That's not helpful.
Bug: http://b/297317502
Test: treehugger
Change-Id: Icf8f734a129fe73ec740bb7cfbb11deb01a98cb3
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
"""
__swsetup: set error flag and errno on error.
Previously, we set errno to EBADF if the cantwrite() macro (which calls
__swsetup()) returns true for POSIX compliance. However, we neglected
to also set the error flag, __SERR. Rather than set the error flag in
all callers of cantwrite(), set both errno and the error flag in
__swsetup(). This matches what FreeBSD does and makes it possible
to choose a proper errno value for the second error condition in
__swsetup(). OK deraadt@
"""
fc99cf9338
Bug: http://b/302742247
Test: treehugger
Change-Id: If3be4905fc21e513cb8718cca671eae3885e411a
The code comment that's being removed here defends the old
implementation by claiming that it's faster. Annoyingly, we don't know
what hardware that was run on. Running on current-ish hardware
(cheetah), I can't really tell the difference except: (a) for hwasan,
avoiding the unsafe memory access by _not_ using the array is a huge
win, and (b) even for arm32 the logic is (very slightly) faster than the
array lookup.
So let's get rid of the unsafety (as musl and FreeBSD have already done)
and the large hwasan slowdown (10ns vs 2ns). It's possible in-order
cores might still care, but it's 2023 and it's time to move on.
This change _does not_ remove `_ctype_` and associated macros from the
headers, though we might want to come back and do that. Historically
libc++ used these implementation details directly, but that's no longer
the case, and it seems unlikely that anyone else is, and today's results
suggest they probably shouldn't anyway, and doing so only ever really
made sense for something like ISO-Latin-1 anyway. Most ASCII tests are
_always_ better off inlined, and Android's never supported non-ASCII for
<ctype.h> anyway (use the isw*() functions if you want that, but bear in
mind that if you're actually dealing with human languages, you probably
want icu4c rather than libc anyway).
Test: treehugger & benchmarks
Change-Id: Ifac25c23ac33e996a3c726317b5c6e602dc72e30
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
These targets were created for multi-tree. This use case is not very
relevant anymore, so cleanup these BUILD files
Test: m nothing
Test: presubmits
Bug: 284029211
Change-Id: Id2680df9cfe291ca10b4f007bbd05a338b2498c1
