Use arch-specific LOCAL_ variables to build libm for both
TARGET_ARCH and TARGET_2ND_ARCH.
Bug: 11654773
Change-Id: I6da794ba722bb68e7484d8869c6eb0425b7d17cb
libunwind has #define inline /* empty */ which breaks our fortified headers.
glibc uses __inline but our BSD-derived headers often override that. __inline__
is the third alternative understood by GCC that -- as far as I know -- neither
the C library itself nor third-party code tries to mess with.
Bug: 12871594
Change-Id: I6677e70ea531bb7d4c46021b43af760d4ad8ecf7
As suggested here: https://android-review.googlesource.com/#/c/71267/
it may be used for x86_64 libunwind enabling.
Change-Id: I21623261a48ea7099e030d33932556e294d226ff
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
Some system functions like munmap expect soinfo's size to be size_t, but currently
it is unsigned. Change it to size_t to fit 64bit's portability.
Change-Id: I0bf6d522b38b0cd9bf1db05b004b5326217412a2
Signed-off-by: Weiwu Chen <weiwu.chen@intel.com>
Signed-off-by: Qiming Shi <qiming.shi@intel.com>
We don't actually need to worry about sign extension if we reject
negative values ourselves. Previously it was possible to come up
with negative but aligned values that we would pass to the kernel;
in the case of mmap (as opposed to mmap64) we'd incorrectly turn
those into large positive offsets.
Change-Id: I2aa583e0f892d59bb77429aea8730b72db32dcb0
Do not use the magic number 0xFFFFFFFFU to represent the max value of an address
as it's not correct on 64bit platform. We should use UINTPTR_MAX instead.
Change-Id: I1fc6f5864a651b2eddea2333cb0788f9d9223270
Signed-off-by: Qiming Shi <qiming.shi@intel.com>
Signed-off-by: Weiwu Chen <weiwu.chen@intel.com>
The various committees decided that everyone should get all these macros,
all the time.
Bug: 12708004
Change-Id: Ib56010dcba9b0656e5701546fefb7f78dc0bf916
This is required to make the Nexus 10 graphics driver work on a system
compiled with gcc 4.9.
Change-Id: If3f3d488652a736d9ea3e583548d74fae3ffa902
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
These functions should print assertion violation messages and then
call abort(). They do really not return control flow afterwards.
Consider the declaration of the similar __assert_fail from glibc:
extern void __assert_fail (const char *__assertion,
const char *__file,
unsigned int __line,
const char *__function)
__THROW __attribute__ ((__noreturn__));
Bionic has __noreturn defined in sys/cdefs.h to be that GNU
noreturn attribute.
This patch has a practical value. Consider the following function:
void check(void* ptr) {
assert(ptr != NULL);
}
Without this patch applied, gcc (and presumably clang) shows even in
debug mode:
warning: unused parameter 'ptr' [-Wunused-parameter]
In release mode, NDEBUG is defined and assert() becomes a no-op, as
one should expect. Thus, the warning is shown correctly then.
Another code sample:
float array[2];
int i = 3;
...
assert(i < 2);
array[i] = 0;
gcc says,
warning: array subscript is below array bounds [-Warray-bounds]
In other words, without noreturn attribute, assertions do not
allow a compiler's static analyzer to properly understand
the preconditions.
Change-Id: I3be92e99787c528899cf243ed448c4730c00c45b
Signed-off-by: Vadim Markovtsev <gmarkhor@gmail.com>
