Add an optimized memset that is ~20% faster for cortex-a7 and
cortex-a53.
Add a 32 bit optimized cortex-a53 memcpy that is about ~20% faster
on cached data.
Fix the cortex-a15 __str{cat,cpy}_chk.S, memcpy_base.S to remove
the phony functions, since they aren't needed any more. Then add
a direct include of these for cortex-a53.
Verified the new functions by stepping through all of the major
paths and verifying the backtrace is still correct.
Bug: 22696180
Change-Id: Iec92a3f82d51243cca76c9aff9f35d920ff865ae
Also remove cruft meant to support long-obsolete compilers. More
benchmarks.
Bug: http://b/23195789
Change-Id: Ief538e41e77a77e8013b2f4f359584e8df2c47d8
This corrects an issue with mips32 Art on mips64r6 Android, where
Java ran slowly due to unintended use of kernel-trap emulation of
single-precision floating point registers. This also regressed all
Art tests due to an extra logcat line
WARNING: linker: Using FRE=1 mode to run "..."
When targeting mips32r6, Art generates modeless or FR=1 floating point
code, same as Android's own native mips32r6 modules. So the trapping was
unneeded. Linker was confusing Art-generated modules with those from
old NDK compilers, which do need that trapping mode.
This linker filename check may become unnecessary, if Art learns how to
generate .MIPS.abiflags segments in its generated elf-like codefiles.
Change-Id: I18069d1234960c680c5df739514da09015a7fdb6
SIGPIPE is a pretty normal way for command-line apps to die, but because
we catch it and report it via debuggerd, we get a lot of bogus bugs. We
could catch SIGPIPE in our tools, but that's not really legit and slightly
misleading.
"But", you say, "catching SIGPIPE is useful for app bugs!". Except a trawl
through buganizer suggests it's misleading there too. Not least because
it's usually an innocent victim that dies --- the problem is usually on the
other end of the pipe (which you learn nothing about because that process
already died, which is what closed the pipe).
We also don't catch SIGALRM, which is another signal that will terminate
your process if you don't catch it, but that one actually represents a
logic error in the crashing process, so there's a stronger argument for
catching that. (Except it too is not a real source of bugs.)
Bug: http://b/20659371
Change-Id: I79820b36573ddaa9a7bad0561a52f23e7a8d15ac
It turns out that everyone's still getting PAGE_SIZE from <sys/user.h> via
<sys/ucontext.h> via <signal.h> anyway.
glibc has PAGE_SIZE in <sys/user.h> rather than <limits.h> so this part is
good. The bad part is that we have such wide transitive inclusion of
<sys/user.h>!
Bug: http://b/22735893
Change-Id: I363adffe4a27b4ca1eedf695ea621f5dd2d5ca10
I'm removing the TODO on the assumption that being compatible with glibc
is more useful than BSD. The new internal "bionic_page.h" header factors
out some duplication between libc and the linker.
Bug: http://b/22735893
Change-Id: I4aec4dcba5886fb6f6b9290a8f85660643261321
