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
Manual changes:
cpp.py: cope with macros that refer to other macros.
defaults.py: x86 no longer always implies __i386__; use __i386__ to replace
the kernel CONFIG_X86_32 flag.
asm/page.h: the upstream page.h isn't a uapi header and no longer includes
the stuff we were using it for. Let's just have our own static file, since
it's the same for all our architectures (both 32- and 64-bit).
sys/select.h: we used to use the various FD_SET-related macros from the
kernel header files, but they've gone. Adjust by adding trivial equivalent
definitions.
Automated changes:
libc/kernel/arch-x86, libc/kernel/common: regenerated from
external/kernel-headers.
Change-Id: I84fc0ed52dc742e043b4ae300fd3b58ee99b7fcd
If "n" is smaller than the size of "src", then we'll
never read off the end of src. It makes no sense to call
__strncpy_chk2 in those circumstances.
For example, consider the following code:
int main() {
char src[10];
char dst[5];
memcpy(src, "0123456789", sizeof(src));
strncpy(dst, src, sizeof(dst));
dst[4] = '\0';
printf("%s\n", dst);
return 0;
}
In this code, it's clear that the strncpy will never read off
the end of src.
Change-Id: I9cf58857a0c5216b4576d21d3c1625e2913ccc03
