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
This test should pass with gcc and fail with clang,
until clang/llvm supports emutls or Android linker supports
ELF TLS models.
BUG: 21082792
Change-Id: Id8c97da52c68ec230c7d26af703f6ed32d53a4fe
On the path that only uses r0 in both the krait and cortex-a9
memset, remove the push and use r3 instead.
In addition, for cortex-a9, remove the artificial function since
it's not needed since dwarf unwinding is now supported on arm.
Change-Id: Ia4ed1cc435b03627a7193215e76c8ea3335f949a
