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: 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
As part of the build, soong runs the following cmd
```
$ versioner -o <out_dir> bionic/libc/include
bionic/libc/versioner-dependencies
```
To migrate this action to Bazel, create a filegroup module for
`bionic/libc/versioner-dependencies`. In Bazel builds, this target will
be copied to the Bazel's sandbox and placed on the include path when
running versioner. This should be a no-op in Soong.
`bionic/libc/versioner-dependencies` is a collection of symlinks, some of
which point to `prebuilts/clang-tools`. Bazel supports incremental
builds with symlinks out-of-the-box, so we do not need to add special
handling for this directory.
Bug: 301169067
Test: m nothing
Change-Id: I7cbb92e2248c194038a5690c81fed945dee61ccc
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
Change our handful of `constexpr static`s to the much more common
`static constexpr`. It's easier to "follow existing style" when there
aren't two existing styles to copy from, and all else being equal,
"majority wins" :-)
Test: treehugger
Change-Id: Ifbf0f62ab84c9450bf9c2e49e96915c126fd20c4
