Make sure the buffer we're dealing with has enough room.
Might as well check for memory issues while we're here,
even though I don't imagine they'll happen in practice.
Change-Id: I0ae1f0f06aca9ceb91e58c70183bb14e275b92b5
memcpy.a15.S/strcmp.a15.S files were submitted by ARM for use as the basis
for the memcpy/strcmp implementations in cortex-a15.
memset.S was moved in to the generic directory.
NOTE: memcpy.a9.S was submitted by Linaro to be the basis for the memcpy
for cortex-a9/cortex-a15 but has not been incorporated yet.
Bug: 10971279
Merge from internal master.
(cherry-picked from 48fc3e8b9f)
Change-Id: I8f9297578990d517f004e4e8840e2b2cbd5a47d8
The check for __ARM_FEATURE_DSP being defined is pointless since it
is always defined.
Bug: 10971279
Merge from internal master.
(cherry-picked from d2642fa70c)
Change-Id: If23ab3271f4da0c38cd531ffdc9a7e5eed6ec5dc
malloc and family were not declared with __attribute__((alloc_size)).
This was (sometimes) preventing FORTIFY_SOURCE related functions
from knowing the size of the buffer it's dealing with, inhibiting
FORTIFY_SOURCE protections.
Add __attribute__((alloc_size))
Information about the alloc_size attribute can be found
at http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
Change-Id: Ia2f0a445f0170a7325f69259b5e7fb35a9f14921
Clang and gcc default to different standards, so we should be explicit
about the versions we want to compile for.
Change-Id: I65495a2392dd29f36373b94c616c2506173e6033
I've no idea what _BITSIZE was supposed to be, glibc doesn't have it,
the BSDs don't have it, and no code is currently using it. But having
it set unconditionally to 32 sounds like a bad idea.
Change-Id: I900235c1489afba891fff0bc3b43e9d593249a4f
Clang (prior to 3.4) does not actually provide a declaration (or definition)
of _Unwind_GetIP() for ARM. We can work around this by writing our own
basic implementation using the available primitive operations.
Change-Id: If6c66846952d8545849ad32d2b55daa4599cfe2c
Use basic .c versions of all functions for x86_64 until they are
manually optimized and .s versions released.
Change-Id: I59bba08931e894822db485c8803c2665c226234a
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
This was causing conflicting declarations for the library definitions of
common functions like sprintf(), snprintf(), and strchr().
Change-Id: I5daaa8a58183aa0d4d0fae8a7cb799671810f576
This is used to set/get TLS on x86_64. There's no public declaration
of this because it's not meant to be used outside the C library, like
glibc (though we don't currently have any visibility controls to ensure
this).
Change-Id: I5fc0a5e3ffc3f4cd597d92ee685ab19568ea18f7
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
This touches the x86 stubs too because arm, x86, and x86_64 now
all share the same header (at a source level), which causes a
reordering of the #include lines.
Change-Id: If9a1e2b2718bd41d8399fea748bce672c513ef84
* Tune syscall stubs generator for 4th target: x86_64
* Update SYSCALLS.TXT with x86_64 syscalls:
- Most of the x86 syscalls are equally supported
- *32 syscalls are not supported on 64-bit
- *64 syscalls are replaced accordingly without 64 suffix
- Some syscalls are not supported, replaced with x86_64 analog
Syscalls are regenerated as separate patch for review convenience.
Change-Id: I4ea2e0f13759b0aa61f05208ca68da8d6bc7c048
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
Copyright headers shouldn't contain the filename (and especially
shouldn't contain a different file's filename).
Change-Id: I82690a3bf371265402bc16f5d2fbb9299c3a1926
