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
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
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
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
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
Also de-pessimize time(), where the vdso entrypoint only exists on
x86/x86-64 anyway.
Bug: https://github.com/google/android-riscv64/issues/8
Test: strace
Change-Id: I14cb2a3130b6ff88d06d43ea13d3a825a26de290
These are the same function for machines with binary floats (that is:
all machines), but ldexp() is in libc rather than libm, so we can't just
use an alias.
We were using this duplicate copy of the code, but upstream FreeBSD has
removed it, and I'd prefer to do the same.
Longer term, we should just move all of libm into libc (but keep an
empty libm for compatibility), but this is probably easier for now.
Test: treehugger
Change-Id: I1a1d6d4f1771316f791ad59c714a3a65aedefc81
This gives us C11 Annex K's qsort_s(), which -- despite being Annex K --
is potentially useful in that it resolves the long-standing argument
about what the signature of qsort_r() is supposed to be. I'll import
it here first, and worry about actually using it separately (given that
glibc/musl and macOS/iOS don't have it; only Windows and [now] FreeBSD,
but not even the other BSDs).
For now, though, this change is a no-op.
Bug: http://b/17203231
Bug: http://b/31807750
Test: treehugger
Change-Id: Id8d2916b608ba8251df8643694da542e9b11eaae
While looking at the disassembly for the epoll stuff I noticed that this
expands to quite a lot of code that the compiler can't optimize out for
LP64 (because it doesn't know that the "copy the argument into a local
and then use the local" bit isn't important).
There are two obvious options here. Something like this:
```
int signalfd64(int fd, const sigset64_t* mask, int flags) {
return __signalfd4(fd, mask, sizeof(*mask), flags);
}
int signalfd(int fd, const sigset_t* mask, int flags) {
#if defined(__LP64__)
return signalfd64(fd, mask, flags);
#else
SigSetConverter set = {.sigset = *mask};
return signalfd64(fd, &set.sigset64, flags);
#endif
}
```
Or something like this:
```
int signalfd64(int fd, const sigset64_t* mask, int flags) {
return __signalfd4(fd, mask, sizeof(*mask), flags);
}
#if defined(__LP64__)
__strong_alias(signalfd, signalfd64);
#else
int signalfd(int fd, const sigset_t* mask, int flags) {
SigSetConverter set = {};
set.sigset = *mask;
return signalfd64(fd, &set.sigset64, flags);
}
#endif
```
The former is slightly more verbose, but seems a bit more obvious, so I
initially went with that. (The former is more verbose in the generated
code too, given that the latter expands to _no_ code, just another symbol
pointing to the same code address.)
Having done that, I realized that slight changes to the interface would
let clang optimize away most/all of the overhead for LP64 with the only
preprocessor hackery being in SigSetConverter itself.
I also pulled out the legacy bsd `int` conversions since they're only
used in two (secret!) functions, so it's clearer to just have a separate
union for them. While doing so, I suppressed those functions for
riscv64, since there's no reason to keep carrying that mistake forward.
posix_spawn() is another simple case that doesn't actually benefit from
SigSetConverter, so I've given that its own anonymous union too.
Test: treehugger
Change-Id: Iaf67486da40d40fc53ec69717c3492ab7ab81ad6
Symbol __rand48_seed, __rand48_mult and __rand48_add are duplicate when switch -fcommon to -fno-common, but this was already fixed upstream, so sync with upstream's version.
Bug: b/151457797
Test: mm
Change-Id: Ie673a4c58671cdac405e0ff313c5898728f7b426
NDK API review complained about missing nullability annotations (added),
not having a `__riscv` #if guard around this function (added), and not
using `__INTRODUCED_IN(35)`. I haven't done the last of these because
that seems less helpful than the traditional "nothing" meaning "always
available" (since this riscv64-only function will be available from
whatever the first riscv64 API level ends up being).
Bug: http://b/291777120
Test: treehugger
Change-Id: I501b42851bd5b1612244bd86351628d249a57b99
No functional change because the syscall wrapper generator doesn't use
the return types, but having the wrong return type is distracting.
Bug: https://github.com/android/ndk/issues/1908
Test: treehugger
Change-Id: I8b1a6ca11247554d28e85cb6c26ad8328c66a2b9
We're not ready to add a syscall wrapper to bionic for this (see
https://www.openwall.com/lists/libc-coord/2023/07/13/1 for more), but it's
useful for writing a CTS test ensuring that misaligned accesses are fast.
(I've also moved userfaultfd() next to membarrier() where it belongs:
the existing comment was incorrect.)
Bug: https://github.com/google/android-riscv64/issues/87
Test: treehugger
Change-Id: Ibe691e461c564caebfed295e7acda73cb9b97618
The obsolete mips header rides again!
The most interesting part of this change is that I've removed the hack
that meant that all system call wrappers starting with `__` defaulted to
being hidden symbols. That's no longer useful given our linker scripts,
and it actively got in the way here because the public libc symbol
actually starts with `__` in glibc, and it would be weird and annoying
for developers if we chose a different name.
Test: strace
Change-Id: I230479787895e8e34f566ade36346a8241eea998
When I added %m to async_safe_* too, we never followed up and cleaned up
callers.
Test: treehugger
Change-Id: If81943c4c45de49f0fb4bc29cfbd3fc53d4a47fe
Failure to mark shadow stack page as writable will result in a SEGV
fault later when a function tries to save return addresses to shadow
stack. The engineer looking at the crash report would be very confused
because the program crashes at very beginning of an innocent looking
function. For ease of debugging, check for shadow stack errors early.
Test: th
Bug: 279808236
Bug: 253652966
Change-Id: Id2da68fa984b5dfb1846ed14aa7ededee7f2508f
