the POSIX standard is that SIZE_MAX is defined
in stdint.h, not limits.h.
Change-Id: Iafd8ec71d1840541feaca4f53b2926b398293fac
Signed-off-by: Webb, Russell <russell.webb@intel.com>
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
Reviewed-by: Ross, Andrew J <andrew.j.ross@intel.com>
Reviewed-by: Boie, Andrew P <andrew.p.boie@intel.com>
Reviewed-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
Tested-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
Our <machine/asm.h> files were modified from upstream, to the extent
that no architecture was actually using the upstream ENTRY or END macros,
assuming that architecture even had such a macro upstream. This patch moves
everyone to the same macros, with just a few tweaks remaining in the
<machine/asm.h> files, which no one should now use directly.
I've removed most of the unused cruft from the <machine/asm.h> files, though
there's still rather a lot in the mips/mips64 ones.
Bug: 12229603
Change-Id: I2fff287dc571ac1087abe9070362fb9420d85d6d
Most of <machine/_types.h> was either unused, wrong, or identical across
all 32-/64-bit architectures.
I'm not a huge fan of <sys/_types.h> either, but moving the bits we need
up into there is a step forward.
Bug: 12213562
Change-Id: Id13551c78966e324beee2dd90c5575e37d2a71e6
This is a better solution than the old __warn_references because it's
a compile-time rather than link-time warning, it doesn't rely on something
that doesn't appear to be supported by gold (which is why you only used
to see these warnings on mips builds), and the errors refer to the exact
call site(s) rather than just telling you which object file contains a
reference to the bad function.
This is primarily so we can build bionic for aarch64; building libc.so
caused these warnings to fire (because link time is the wrong time) and
warnings are errors.
Change-Id: I5df9281b2a9d98b164a9b11807ea9472c6faa9e3
This is basically the other half of I5de76f6c46ac87779f207d568a86bb453e2414de
from Pavel Chupin <pavel.v.chupin@intel.com>, but taking the exact upstream
_types.h instead of the modified version. (I was confused when I suggested
otherwise.)
I've also cleaned up the internal_types.h situation; we weren't gaining
anything from these empty files, and there is no upstream internal_types.h
for x86_64.
Change-Id: I802a9a6a8df1c979e820659212c75a47c2ef392e
This brings us up to date with FreeBSD HEAD, fixes various bugs, unifies
the set of functions we support on ARM, MIPS, and x86, fixes "long double",
adds ISO C99 support, and adds basic unit tests.
It turns out that our "long double" functions have always been broken
for non-normal numbers. This patch fixes that by not using the upstream
implementations and just forwarding to the regular "double" implementation
instead (since "long double" on Android is just "double" anyway, which is
what BSD doesn't support).
All the tests pass on ARM, MIPS, and x86, plus glibc on x86-64.
Bug: 3169850
Bug: 8012787
Bug: https://code.google.com/p/android/issues/detail?id=6697
Change-Id: If0c343030959c24bfc50d4d21c9530052c581837
Replace a kernel header file dependency with files from NetBSD.
They're more complete, and ELF is ELF, whether you're on Linux or a BSD.
Bug: 7973611
Change-Id: I83ee719e7efdf432ec2ddbe8be271d05b2f558d7
Previously we'd been relying on getting the machine-specific <endian.h>
instead of the top-level <endian.h>, and <sys/endian.h> was basically broken.
Now, with this patch and the previous patch we should have <endian.h>
and <sys/endian.h> behaving the same. This is basically how NetBSD's endian.h
works, and was probably how ours was originally intended to work.
Bug: http://code.google.com/p/android/issues/detail?id=39824
Change-Id: I71de5a507e633de166013a658b5764df9e1aa09c
The near duplicates upset fussier compilers that insist that
typedefs be exactly the same, but the fix isn't to make all
copies identical...
Change-Id: Icfdace41726f36ec33c9ae919dbb5a54d3529cc9
We'd manually hacked _BYTE_ORDER into the arm and mips "_types.h" headers,
but not into the x86 one. Judging by upstream, _BYTE_ORDER should be in
the "endian.h" headers instead, so let's uniformly do that.
I've also ironed out some of the other differences between the different
architectures' header files too.
Bug: http://code.google.com/p/android/issues/detail?id=39824
Change-Id: I19d3af7ffd74e1c02b1b6886aec0f0d11f44ab8d
This patch updates the C library headers to provide ucontext_t
definitions for three architectures.
+ Fix <signal.h> to always define 'struct sigcontext'.
The new declarations are announced with new macros defined in
<sys/cdefs.h> in order to make it easier to adapt client code
that already defines its own, incompatible, versions of the
structures seen here.
http://code.google.com/p/android/issues/detail?id=34784
Change-Id: Ie78c48690a4ce61c50593f6c39639be7fead3596
This patch defines a few new macros that can be used to control the
visibility of symbols exported by the C library:
- ENTRY_PRIVATE() can be used in assembly sources to indicate
that an assembler function should have "hidden" visibility, i.e.
will never be exported by the C library's shared library.
This is the equivalent of using __LIBC_HIDDEN__ for a C function,
but ENTRY_PRIVATE() works like ENTRY(), and must be used with
END() to tag the end of the function.
- __LIBC_ABI_PUBLIC__ can be used to tag a C functions as being
part of the C library's public ABI. This is important for a
few functions that must be exposed by the NDK to maintain
binary compatibility.
Once a symbol has been tagged with this macro, it shall
*never* be removed from the library, even if it becomes
directly unused due to implementation changes
(e.g. __is_threaded).
- __LIBC_ABI_PRIVATE__ can be used for C functions that should
always be exported by the C library because they are used by
other libraries in the platform, but should not be exposed
by the NDK. It is possible to remove such symbols from the
implementation if all callers are also modified.
+ Add missing END() assembly macro for x86
Change-Id: Ia96236ea0dbec41d57bea634b39d246b30e5e234
Add a macro to annotate function end and start using both ENTRY and END
for each function. This allows valgrind (and presumably other debugging
tools) to use the debug symbols to trace the functions.
Change-Id: I5f09cef8e22fb356eb6f5cee952b031e567599b6
The change explicitly isolates the assembly-only macros in header
<machine/cpu-features.h> in order to prevent mis-inclusion in C/C++
source files.
Change-Id: I0258e87c5ac3fd24944fb227290ac3b9cac4bfba
Added an underscore to _ARM_HAVE_LDREX_STREX to make it match the others.
Added __ARM_HAVE_DMB and __ARM_HAVE_LDREXD when appropriate.
Fixed some typos.
Change-Id: I2f55febcff4aeb7de572a514fb2cd2f820dca27c
ARMv6 onwards. These architectures provide the load-linked, store-conditional pair of ldrex/strex whose use
is recommended in place of 'swp'. Also, the description of the 'swp' instruction in the ARMv6 reference
manual states that the swap operation does not include any memory barrier guarantees.This fix attempts to
address these issues by providing an atomic swap implementation using ldrex/strex under _ARM_HAVE_LDREX_STREX
macro. This Fix is verified on ST Ericsson's U8500 platform and Submitted on behalf of a third-party:
Surinder-pal SINGH from STMicroelectronics.
