* When calculating the required guard, if a per-arch `introduced`
value is less than the arch min-API, drop the per-arch guard (i.e.
reset the value to 0). This is needed for RISC-V, where we don't
parse the headers with Clang, because the highest APIs we compile
for (e.g. 23, 34) are less than the current RISC-V min API of 10000.
Resetting it to 0 here means we don't need this optimization while
generating an arch-set guard. (i.e. We don't need to calculate
max_min_version. That code should have been calculating a
"min_min_version" anyway.)
* Remove the broken all-supported-archs entry from arch_sets. It has a
few problems:
* It's redundant with the "global availability" code path above,
which is used when the declaration has no per-arch annotations.
* If this code path runs, then we generate two more guard
expressions, for !LP64 and LP64.
* Passing "" to generate_guard is broken for a non-zero version,
and for a zero version, adding an empty string to `expressions`
breaks if the vector has 2 or more expressions.
(I think consolidating per-arch info, e.g. using a single check for
__INTRODUCED_IN_32(40) __INTRODUCED_IN_64(40), is a nice idea, but
it should happen as a natural consequence of removing the
arch-independent "global availability" info in favor of always
tracking it per-arch.)
* Rewrite the arch-set guard generation. Add an optimization so that
the (__ANDROID_API__ >= N) guard for __INTRODUCED_IN_64(N) is still
useful for RISC-V as long as N is small enough. (Currently we're
checking that N is <= 10000.)
This change fixes the "preprocessor" test that run_tests.py runs. The
"slow_preprocessor_idempotence" test is still broken.
Bug: https://github.com/android/ndk/issues/1888
Test: run_tests.py
Change-Id: I3f94357465dbdb2c23fff442a31fb5083de27a97
At least one person wasn't entirely convinced by our existing riscv64
documentation, and there was an error in the 32 vs 64 section.
Test: N/A
Change-Id: Iaa08b8f4b5a5506a4ade15f81e17325185036a07
Using the AndroidLocalUnwinder object allows unwinding interpreter
and JIT'd frames by default. In addition, it simplifies the code.
Test: Forced interpreter on all of the time and forced fdtrack on
Test: and verified unwind includes dex frames.
Test: Forced JIT on all of the time and forced fdtrack on
Test: and verified unwind includes dex frames.
Test: Unit tests pass.
Change-Id: Icae17e83c9aaa04750b07471243550a7829524f7
Neither is great, but "gp" seems actively misleading (and setjmp.S
says x3 every time, so we should be consistent if nothing else).
Bug: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/379
Test: treehugger
Change-Id: Ibccda74d4794caa770b82e7ba2e31ce7b645b83f
We don't actually care about the length of this jump, and lld will relax
it to a jal when possible anyway. Better to have people copy & paste
call and tail than jal and j.
Test: treehugger
Change-Id: I889044b95fbb5567189a0d6ef31f81df0e0383cd
The only remaining differences between vfprintf.cpp and vfwprintf.cpp
after this are the wide/narrow conversions for %c, %m, and %s. I've used
"chars" and "bytes" for the named constants for the directions because
(a) I find -1 and 1 pretty confusing and (b) although "narrow" is the
obvious opposite of "wide", only Windows actually moved to wide
characters, so "narrow" (aka "multibyte", and probably "utf8") is the
default/normal case. Even though C confuses bytes and characters via its
`char` type, "bytes" versus "chars" seems like the appropriate
terminology (and it's what Java/Python use).
Also improve the swprintf tests assertion so failures are readable.
Test: treehugger
Change-Id: Ife8f70f65ec28d96058a7d68df353945524835d2
wprintf doesn't need this (and already only has the iov stuff because
the non-wide printf implementation needs it), but we can further reduce
the diff between the two implementations by defining a no-op FLUSH() for
wide characters.
Test: treehugger
Change-Id: Ifefcb4b8474b086f995e2b0796f61558a19e2a42
This reduces the amount of boilerplate for these tests, and ensures that
we have a corresponding swprintf() test for every snprintf() test
(except the handful where it doesn't make sense; we have no FORTIFY for
the wide-character routine, for example).
Test: treehugger
Change-Id: I14091683494bbb414f1a72bddc9835b86ff62526
Jens Gustedt suggested a better implementation last year on the musl
mailing list: https://www.openwall.com/lists/musl/2022/11/19/1
It means the constants are sparse, but in return it means we can add
future constants and they'll be backward compatible. (Sadly you'll need
to be on API level 35 before you can use anything but TIME_UTC.)
I doubt this will ever matter, because everyone should just stick to
clock_gettime()/clock_getres() anyway, and anyone who does have a
legitimate use for timespec_get() and timespec_getres() probably needs
to support non-Linux and so can't use any clocks that aren't in ISO C
anyway. But given that we don't _have_ to paint ourselves into a corner
here, we may as well take the opportunity to not do so.
Test: strace
Change-Id: I293d32fcbcf7f6703564dac0978ae2a10192a482
