Looks like I'd been bad here, and added new stuff to this file rather
than <elf.h> directly. I've also done nothing to upstream any of this.
This patch at least addresses the former problem, moving our stuff out
into <elf.h>.
Rather than *delete* anything that conflicts with Linux in elf_common.h,
I've disable it with // or #if, and marked those as Android changes to
make it less likely that the next update accidentally drops them (which
isn't super likely, since most of them should actually cause build
failures when they conflict with uapi).
Test: treehugger
Change-Id: Id0deccc7305c60b0f708b55e2eed0dedc0bca41d
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
When 'no page size' is turned on (especially if it is turned
on by default in some environments), we need a way to turn
it off, thus restoring the old behavior.
Bug: 312546062
Change-Id: I411cff621246b6ba40e70bb51234f3886ba9527a
Test: N/A
This is for advanced use-cases that have high performance demands and
know they will repeatedly re-use the crash_detail.
Bug: 155462331
Change-Id: Ib15dac70d1d598f78b74b539aeadf88b0ca32bc7
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-6.7
NOTE: The file bionic/libc/kernel/uapi/linux/usb/f_accessory.h was
deleted in the 6.7 kernel along with the functionality. However,
there is no current replacement. For now keep the file here, but at
some point when the new implementation is ready, this file will need to
be moved to the places that still need to be backwards compatible.
Test: Builds and bionic unit tests pass on raven.
Test: Able to log in to an Android GO 32 bit device.
Change-Id: Ibf5684ed140616c02bb9464bbd6422a9281a29cf
Set PTHREAD_STACK_MIN will be set to:
- 16384 for 64-bit arch
- 8192 for 32-bit arch
Bug: 315174209
Test: Built and start the targets
- aosp_cf_arm64_phone_pgagnostic
- aosp_cf_x86_64_phone
Change-Id: I8bb20a3433e615f9f80a0d52051f2e1635d4301a
This way, callees don't need to worry about whether or not their
reference to __riscv_hwprobe() has been resolved before their ifunc
resolver is called.
This matches the current glibc proposal from rivos.
Test: treehugger
Change-Id: I0d5244aa837d0d1f0e6bd7d22091dfedb8a55bdb
There is no need to use PAGE_SIZE to define the value of
PTHREAD_STACK_MIN.
Bug: 312546062
Bug: 313941999
Test: source build/envsetup.sh
lunch aosp_cf_arm64_phone_pgagnostic-trunk-userdebug
m
Change-Id: If3c3fe39f50592df58634d1c164e87dcd0aebad0
This works out a bit silly/ugly because the bits/ header file has the
wrong name, so I've also changed the map from kernel struct to boolean
to be a map from kernel struct to filename. That not only fixes this,
it's a bit more readable too. (Just yesterday, when I had no real reason
to change it, I was asking myself "why is this a boolean?"!)
Bug: http://b/236042740
Test: treehugger
Change-Id: I3eee25b493ea97d46cc5dc5fde07f7c5e77d2a46
No-one's hit this in practice, that I know of, but there are very few
instances of this old workaround for kernel/userspace mismatches still
present, and (as part of the much harder and less effective `struct
sigaction` cleanup), we should just remove them.
Bug: http://b/236042740
Test: treehugger
Change-Id: I6c71d4353044cf57cfa8a9796a4c3d6a4d51cd86
Before this change, we have the kernel's sigaction in the uapi headers,
and our own sigaction in <bits/signal_types.h> and we rely on callers
making sure to use `#define` to move the kernel type out of the way if
they include a uapi header directly. This is obviously error-prone and
undesireable, and not what we usually do now.
What we _usually_ do now is use the header scrubber's ability to replace
a struct definition with a `#include <bits/STRUCT.h>`, but that doesn't
work here because struct sigaction relies on a lot of other types,
some of which also come from uapi headers.
So instead use our second best trick, which is to "move the kernel struct
out of the way" at header scrubbing time instead. This means that someone
who does `#include <linux/signal.h>` or `#include <asm/signal.h>` won't
get `struct sigaction` (they'll only have `struct __kernel_sigaction`
instead), but it does mean that they can't get two incompatible
definitions if they include a uapi header both directly and indirectly.
So although this doesn't do what I'd set out to do, it's still an
improvement in some cases, and it's our preferred idiom in most cases
anyway. (I'll come back once this is in to tidy up the two other kernel
structs where we're still using the deprecated "rename out of the way
using #define" trick, but this change is already hairy enough, and
there's a possibility it will break code that didn't care that it was
getting the kernel `struct sigaction` rather than the userspace one.)
Bug: http://b/236042740
Test: treehugger
Change-Id: Icff50e330c09c587e8f77ba0fb7cffffd9c3b708
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
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
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
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
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
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
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
