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>
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
I did look at a wider cleanup of libc/arch-x86_64/string/*.S but was
horrified by what I found there, with apparently-useless macros that
may actually be relevant because source files include each other. So
I'll leave the Intel-written stuff alone until/unless I actually have
reason to touch it, and just clean up our corner instead.
Test: treehugger
Change-Id: Id749f79d2fab4a2956efe9e807a067e16cd606ec
Block allocator mmaps arbitary large area ("LinkerBlockAllocatorPage")
of size 4kB * 100. In order to reduce mmap-* syscall and kernel VMA
memory usage.
This works fine for 16kB page size since 100 4kB page are equal to 25
16kB pages.
But for 64kB page size the area will include a partial page (16kB sized
region at the end).
Change the size to 96 4kb pages (6 64kB pages), this will work for all
aarch64 supported page sizes.
And remove the use of PAGE_SIZE
Bug: 294438799
Test: atest -c linker-unit-tests
Change-Id: I7782406d1470183097ce9391c9b70b177e1750e6
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
* changes:
Improve output for failed wcsto* tests.
Add missing setlocale/uselocale for glibc tests.
Fix test for out of range multibyte characters.
Fix wchar tests for zero length conversions.
Fix wcsto*_l tests for glibc.
This lets us remove the riscv64 "sys/asm.h" file. It turns out everyone
loves this macro --- tons of x86 and arm assembler is already using it!
I'll clean up some of the now-duplicate definitions separately, and I'll
move the assembler we wrote ourselves over to this macro (rather than
the current `.L_foo` style) too.
Test: built riscv64 _and_ arm/arm64 _and_ x86/x86-64
Change-Id: If3f93c9b71094a8bed1fd1bb81bb83ec60ce409e
Under some circumstances, it's possible to fail the enable allocation
limit android_mallopt call. Increase the total allowed time for the
function to complete.
In addition, if the enable fails, allow another limit call to succeed
in the future.
Finally, change the limit test to use _exit instead of exit.
Bug: 291672185
Test: Ran limit test thousands of times.
Test: Forced the limit to fail and verified the second call passes.
Change-Id: I0948e6fd97231a7538b9b82b76f0a207386681b1
The magic numbers that C defines are obnoxious. We had partial
definitions for these internally. Add the missing one and move them to
a public header for anyone else that may want to use them.
Bug: None
Test: None
Change-Id: Ia6b8cff4310bcccb23078c52216528db668ac966
We've had these backward all this time. The relevant quote is in a
code comment in the implementation, but the first call after
completely decoding a code point that requires a surrogate pair should
return the number of bytes decoded by the most recent call, and the
second call should return -3 (if only C had given those some named
constants that might have been more obviously wrong).
Bug: https://issuetracker.google.com/289419882
Test: Fixed the test, tests run against glibc and musl to confirm
Change-Id: Idabf01075b1cad35b604ede8d676d6f0b1dc91e6
Same as in uchar_test.cpp: glibc implements a much older unicode
standard which allows these.
Bug: None
Test: this is a test
Change-Id: Iead5eb01d391be85a7b1a034ea9e7f8828e81cdb
Same as the previous change for the uchar tests: the tests are wrong
to match bionic's wrong implementation. Fix the test to encode the bug
for now while I get the tests into good shape, then I'll be back to
fix the bugs and remove the test differences.
Bug: None
Test: this is a test
Change-Id: I1123660994f755f8bac1f2656f6890d5a43310b3
glibc immediately dereferences the locale passed to all wcsto*_l
functions, even if it won't be used, and even if it's
LC_GLOBAL_LOCALE, which isn't a pointer to valid memory.
Bug: None
Test: this is the test
Change-Id: Ia307cbd6a5c5b4b904c978a03e6d06c1cef6ceed
Not necessary (as demonstrated by the lack of this for x86), but this
saves one stack frame in aborts, which gets you one more useful stack
frame in logs and clustering etc, which improves your chances of finding
your bug.
Test: crasher64 abort
Change-Id: Ieb214f3b46520161edc1e53c0d766353b777d8ba
Those flags were used to suppress ABI tidy errors, but by now are not in
use anymore and can safely be removed.
Bug: 156513478
Change-Id: Ibc9625d139f933e48ebb4ddebe70d424f6231f3f
Signed-off-by: Matthias Maennich <maennich@google.com>
glibc maintainer Florian Weimer pointed out that glibc passes a null first
argument to riscv64 ifunc resolvers. While not super useful right now,
that does make it much easier to switch to providing arguments in future,
such as my favorite idea of passing a default set of hwprobe key/value
pairs, along with a count of how many pairs.
Test: treehugger
Change-Id: Ibe2148dc28aa6ad230e6324b6d725fe472b7ef33
