Now the NDK doesn't support API levels below 21, we don't actually need
the different arm32 vs x86 annotations. In general we haven't been
removing this historical information because it might be interesting to
someone, and there's no real reason to remove it, but we've had
versioner bugs recently with these more complex cases.
Test: treehugger
Change-Id: I9460109a2648b9d05d7e21e397935293d3fea8eb
No actual effect on the code, but misleading and wrong. (The previous
change only fixed the argument types; I didn't notice that some of the
return types were wrong too.)
Test: treehugger
Change-Id: I1ee5c48e2652fd8cbf8178d5659e57f79e61898e
* 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
