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
A clang update enabled -Wreorder-init-list by default. Since it doesn't
provide any benefit to the bionic code, disable the warning.
Test: Builds without warnings.
Change-Id: I5891527ef532b59dc2a02b39a5896112411d21f5
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-6.5
Test: Builds and bionic unit tests pass on raven.
Test: Able to log in to an Android GO 32 bit device.
Change-Id: Ia0397ce27e088bc20338bbd2d125be6f169c4ba0
These should never be particularly long, but because this code runs
before we can allocate, they have to be fixed size. Bring that size down
to 128 bytes which should be enough for anyone, and which should let us
add some new filenames in less space than we're currently using for one
filename.
Test: treehugger
Change-Id: I524d7e5ffd415ba0c3d600eb94801a304b1b4bb4
With the cgroups support, this is starting to look like something we
might actually want to use one day. Start preparing now.
Test: treehugger
Change-Id: I7c015bbf6b145b66124ee9ce74816c03e51df7c8
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
Missed this when we added the new C23 binary output to the printf()
family.
Also fix %X to use "0X" instead of "0x" and add missing tests.
Test: used by new LD_SHOW_AUXV functionality
Change-Id: I6623b92acec7daf534536697de0f87352a2653ad
The alignment of kShadowSize to a page sized multiple is
not explicitly needed, since mmap() will return a page-sized
multiple mapping.
kCfiCheckAlign remains 4k as this is chosen by the clang
compiler. [1] [2]
[1] 3568976375/clang/lib/CodeGen/CGExpr.cpp (L3433)
[2] https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html#cfi-shadow
Bug: 296275298
Test: Boot 16kb device, check no cfi failures.
Test: atest -c bionic-unit-tests
Change-Id: Iac0c129c413afe01389f529f5c64051c4ffff2df
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Page size agnostic targets will have a pthread stack equals
to 65536. Page size agnostic targets will only support ARM64 arch.
For not agnostic builds, PTHREAD_STACK_MIN will remain the same.
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: Ifcc04a9d924501f686cdfec34428d3f29154fdf0
If we're going to need PAGE_SIZE in other places, we don't want the
namespace pollution of pulling in all of <sys/user.h>. (The experimental
support for non-4KiB pages found an existing place -- <pthread.h> --
where we were assuming PAGE_SIZE is already available, as if
<sys/user.h> has already been included, so that was actually an existing
bug.)
Test: treehugger
Change-Id: Icd90ffbca1f2cf3645fadb2e432f6f45a4d63eb6
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
Today's risc-v psABI meeting brought up the topic of CFI-related ABI
changes, and FreeBSD wasn't worried about jmp_buf because they already
had twice the space we do (OpenBSD matches us, presumably because they
too just picked "the next power of two" over what they actually
required), and glibc wasn't worried because they have a hilariously
large sigset_t that they can steal space from (and apparently already
did to support the x86-64 CET shadow stack).
So rather than continue to assume that our minimal amount of free space
will suffice, let's just double it while our ABI isn't yet fixed, and
know we won't have to worry about it in a couple of years time when we
actually have riscv64 hardware shadow stack.
Test: treehugger
Change-Id: I2d4cb2f5db2ac8085a2c9e9ad4f910d0d4792005
In the 4k targets there is no fucntional difference since
max_page_size() == page_size() == 4096.
On a 16kb device max_page_size() == 65536 and page_size() == 16384.
However, aligning up does not incur any memory regressions
since the .bss section is still be backes in page-sizeed chunks.
See: go/16k-page-aligned-variables
Bug: 296275298
Test: mma
Change-Id: I41c3e410f3b84c24eeb969c9aeca4b33a8d6170a
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
This can be used to "page-align" variables at build time -
__attribute__((aligned(max_pge_size()))), so it is a
preprocessor macro instead of an inline function.
There is no functional change to the 4kB-only build targets
(!defined(__BIONIC_NO_PAGE_SIZE_MACRO))
Bug: 296275298
Test: mma
Change-Id: I462e9f971a176b6b59e32e449a2e11f95c3f1b45
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
