This is the first patch out of a series of patches that add support for
AArch64, the new 64bit execution state of the ARMv8 Architecture. The
patches add support for LP64 programming model.
The patch adds:
* "arch-aarch64" to the architecture directories.
* "arch-aarch64/include" - headers used by libc
* "arch-aarch64/bionic":
- crtbegin, crtend support;
- aarch64 specific syscall stubs;
- setjmp, clone, vfork assembly files.
Change-Id: If72b859f81928d03ad05d4ccfcb54c2f5dbf99a5
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
This patch adds support for AArch64 atomic operations. Some
of the stubs use the lightweight store/load exclusive.
Change-Id: Iaf704d048b2dc15bf08cf8e4f0c3ea9f2052fe13
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
It looks like we can probably just use the generic GCC stuff instead;
the generated code looks pretty similar. We should come back to that.
These routines are only used by the pthread implementation, and
__bionic_atomic_inc isn't used, so we can remove it.
Change-Id: I8b5b8cb30a1b159f0e85c3675aee06ddef39b429
The original structure included four reserved 32-bit values. This
change adds these back into the structure so that the
__system_property_find_compat function will (again) process the system
properties correctly.
I fixed this bug a while back, but didn't remove it from the list,
could have added a better test, and could have written clearer code
that didn't require a comment.
Change-Id: Iebdf0f9a54537a7d5cbca254a5967b1543061f3d
Under valgrind ehdr_vdso is null and causing segfault.
Adding debug info for vdso producing plenty of issues on debugging
through gdbserver, removing it. It doesn't seem it should be here.
Unwinding through vdso test still works.
Change-Id: I1a7e233c493f2268d725fa8d7279822d07decc49
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
For 64bit Architectures mmap() is equivalent to mmap64(). This patch
maps mmap64() to mmap() in a similar way to other syscalls that differ
based on the size of off_t and off64_t
Change-Id: If21b21ef71120bad23d9a608d02d4a7de5220a87
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
Most callers won't check for EINVAL, so it's best to fail early.
GCC takes the nonnull attribute as a guarantee that an argument
won't be NULL, so these hacks were already ineffective, which is
how we found that at least one commercial game was using NULL
as if it's a mutex, but actually getting no-op behavior.
Bug: 11971278
Change-Id: I89646e043d931778805a8b692e07a34d076ee6bf
