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
Use max_page_size() for build time variable alignments instead
of PAGE_SIZE.
In the 4k targets there is no functional 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/.data sections are still be backed in PAGE_SIZE'ed
chunks. See: go/16k-page-aligned-variables
Bug: 296275298
Test: mma
Change-Id: Ic944235d8a5742a51a8fb0f2a0b75e532f404110
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
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
This list has diverged between cts/ and bionic/. Instead of having to
maintain the list, let's just make cts/ inherit the one from bionic.
Bug: 296832150
Test: atest bionic-unit-tests CtsBionicTestCases
Change-Id: I271668e83aed239107b9129dfb707f03bae47cfa
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>
__linker_init calls soinfo::~soinfo after __linker_init_post_relocation
has returned, and ~soinfo modifies global loader state
(g_soinfo_handles_map), so the loader lock must be held.
Use a variable with a destructor (~DlMutexUnlocker) to release the
loader lock after ~soinfo returns.
It's not clear to me when the mutex should be acquired.
pthread_mutex_lock in theory can use __bionic_tls (ScopedTrace), but
that should only happen if the mutex is contended, and it won't be.
The loader constructors shouldn't be spawning a thread, and the vdso
shouldn't really have a constructor. ifunc relocations presumably don't
spawn a thread either. It probably doesn't matter much as long as it's
held before calling constructors in the executable or shared objects.
Bug: http://b/290318196
Test: treehugger
Test: bionic-unit-tests
Change-Id: I544ad65db07e5fe83315ad4489d77536d463a0a4
AT_PAGESZ is the correct argument for getauxval() to get the page size.
Bug: 277272383
Test: source build/envsetup.sh
lunch aosp_cf_arm64_phone_pgagnostic
Change-Id: Ied2db77e9fda73b58f65b2f489ad7fab743c2fe7
Also fix a __has_include() that was copy & pasted without modification
from a different test.
Test: treehugger
Change-Id: Iafceb331a95ec788596ffdad60aa2202b692e589
When the C flag -D__BIONIC_NO_PAGE_SIZE_MACRO is defined,
the PAGE_SIZE macro won't be used for page size agnostic builds.
Note: Only arm64 architectures support page size agnostic builds.
Bug: 277272383
Bug: 289419664
Test: source build/envsetup.sh
lunch aosp_cf_arm64_phone_pgagnostic
m
source build/envsetup.sh
lunch aosp_cf_x86_64_phone
m
Change-Id: I755d5fcdd493fe6da5277a60d8e90805e9b2754d
When the C flag -D__BIONIC_NO_PAGE_SIZE_MACRO is defined,
the function getauxval(AT_PAGESZ) will be called instead of
using the PAGE_SIZE macro for the arm64 architectures.
Bug: 277272383
Bug: 289419664
Test: source build/envsetup.sh
lunch aosp_raven_pgagnostic_64-userdebug
m
source build/envsetup.sh
lunch aosp_cf_x86_64_phone
m
Change-Id: Ie904ee5601365abbcf93ee371922a351844eccff
Presumably "bt" was "binary tree", but "trie_node" is a bit more
specific and removes the guesswork.
Test: treehugger
Change-Id: Ib5fb2dcbcf261ce516728099d484ed9cd6c069bd
