I broke the mips build yesterday because it doesn't use
<private/bionic_asm.h> like the other architectures, including mips64.
I want to move mips closer to mips64 to try to avoid this kind of thing
in future.
Change-Id: Idb985587ff355b9e5e765c1f5671dc0144cd2488
Turns out stlport isn't broken. <cmath> (included
transitively via gtest in our case) is not required
to make C99 math macros (like signbit) available, nor is
it required to preserve them if they're already defined.
It is only required to make the equivalent functions in
namespace std available.
I couldn't find any documentation of required behaviour for
programs that include both <math.h> and <cmath>.
I've verified experimentally that llvm's libc++ and gnu
stl behave the same as stlport.
bug: 12935307
Change-Id: I9dc5cc0fd9f4f259abc8eefb280177cdd092a94b
When bionic's dynamic linker processes the .dynamic section of a MIPS ELF binary and encounters the DT_MIPS_RLD_MAP dynamic array tag, it calculates the address of where to write a pointer to the _r_debug structure. The current implementation simply reads the value given in the d_ptr field and writes the pointer address to that location. However, this value has to be adjusted to reflect the real load address of the binary. Otherwise the linker will write to a faulty location possibly resulting in a crash when linking a MIPS binary that includes DT_MIPS_RLD_MAP. This change corrects that problem.
Change-Id: I1a91874f7ab47289001fe72d9016660c14c70362
Signed-off-by: Benjamin Adolphi <b.adolphi@gmail.com>
This gives us:
* <dirent.h>
struct dirent64
readdir64, readdir64_r, alphasort64, scandir64
* <fcntl.h>
creat64, openat64, open64.
* <sys/stat.h>
struct stat64
fstat64, fstatat64, lstat64, stat64.
* <sys/statvfs.h>
struct statvfs64
statvfs64, fstatvfs64.
* <sys/vfs.h>
struct statfs64
statfs64, fstatfs64.
This also removes some of the incorrect #define hacks we've had in the
past (for stat64, for example, which we promised to clean up way back
in bug 8472078).
Bug: 11865851
Bug: 8472078
Change-Id: Ia46443521918519f2dfa64d4621027dfd13ac566
bionic/libc/arch-arm64/syscalls/read.S ends with:
b.hi __set_errno
ret
END(read)
If __set_errno returns int, it will set w0 to 0xFFFFFFFF, which means
x0 is 0x00000000FFFFFFFF. When interpreted as a ssize_t that is
INT_MAX, not -1.
Change __set_errno to return long, which will cause x0 to be set instead
of w0.
Change-Id: I9f9ea0f2995928d2ea240eb2ff7758ecdf0ff412
These were needed when bionic's header files were missing these macros (though
it would have made a lot more sense to just fix the header files!) but cause
warnings now.
Change-Id: I65a677122f4f6bd07dffc3f37a0c4c0e823d1bb0
We don't need quite so much duplication because we already have a way
to get the signal number from its name, and that already copes with the
fact that the mips/mips64 numbers are different from everyone else's.
Also remove sys_signame from LP64. glibc doesn't have this BSD-ism.
Change-Id: I6dc411a3d73589383c85d3b07d9d648311492a10
1. Moved arch-specific setup to their own files:
- <arch>/<arch>.mk, arch-specific configs. Variables in those config
end with the arch name.
- removed the extra complexity introduced by function libc-add-cpu-variant-src,
which seems to be not very useful these days.
2. Separated out the crt object files generation rules and set up the
rules for both TARGET_ARCH and TARGET_2ND_ARCH.
3. Build all the libraries for both TARGET_ARCH and TARGET_2ND_ARCH,
with the arch-specific LOCAL_ variables.
Bug: 11654773
Change-Id: I9c2d85db0affa49199d182236d2210060a321421
Our sigset_t definition hasn't been tied to our NSIG definition since we
switched to uapi headers, so we can now fix it without breaking the LP32 ABI.
The kernel uapi headers define and use _NSIG, so we need to have our scripts
rename the kernel's definitions out of the way, then we can define _NSIG
and NSIG in terms of the kernel's off-by-one value.
Bug: 12938442
Change-Id: Ic7c86fd5be5ad1d822f7b2b1d88c8a0d70a1ac0f
No cacheflush for LP64; use the GCC builtin instead. Clean up the
32-bit MIPS implementation now we no longer need to worry about
old versions of GCC.
Bug: 12924756
Change-Id: Ie23955b3ec194e226c4b2bce35b11d5e061f4753
