No cacheflush for LP64; use the GCC builtin instead. Clean up the
32-bit MIPS implementation now we no longer need to worry about
old versions of GCC.
Bug: 12924756
Change-Id: Ie23955b3ec194e226c4b2bce35b11d5e061f4753
Remove the linker's reliance on BSD cruft and use the glibc-style
ElfW macro. (Other code too, but the linker contains the majority
of the code that needs to work for Elf32 and Elf64.)
All platforms need dl_iterate_phdr_static, so it doesn't make sense
to have that part of the per-architecture configuration.
Bug: 12476126
Change-Id: I1d7f918f1303a392794a6cd8b3512ff56bd6e487
Also move some of the stuff that should be in <link.h> out of the
private "linker.h", to make it clearer that these are public API
known to gdb that we can't change.
Bug: 12554197
Change-Id: I830e1260d3d8b833ed99bc1518f1c6b6102be8af
libc/libm support for MIPS64 targets
Change-Id: I8271941d418612a286be55495f0e95822f90004f
Signed-off-by: Chris Dearman <chris.dearman@imgtec.com>
Signed-off-by: Raghu Gandham <raghu.gandham@imgtec.com>
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
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>
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
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>
This patch adds trivial implementations of the missing sys headers
needed by strace. All strace needs are the constants and structures,
so this is enough for now. We can come back and add the functions
if/when we ever need them.
Change-Id: Idb87c1a8b6b1c62f6e16ae94f147e1169722b48e
The situation here is a bit confusing. On 64-bit, rlimit and rlimit64 are
the same, and so getrlimit/getrlimit64, setrlimit/setrlimit64,
and prlimit/prlimit64 are all the same. On 32-bit, rlimit and rlimit64 are
different. 32-bit architectures other than MIPS go one step further by having
an even more limited getrlimit system call, so arm and x86 need to use
ugetrlimit instead of getrlimit. Worse, the 32-bit architectures don't have
64-bit getrlimit- and setrlimit-equivalent system calls, and you have to use
prlimit64 instead. There's no 32-bit prlimit system call, so there's no
easy implementation of that --- what should we do if the result of prlimit64
won't fit in a struct rlimit? Since 32-bit survived without prlimit/prlimit64
for this long, I'm not going to bother implementing prlimit for 32-bit.
We need the rlimit64 functions to be able to build strace 4.8 out of the box.
Change-Id: I1903d913b23016a2fc3b9f452885ac730d71e001
