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
