valgrind seems to mess with the stack enough that the kernel will
report "[stack:pid]" rather than "[stack]" in /proc/self/maps, so
switch to the task-specific file instead to force "[stack]". (There
are two conditions in the kernel code that decides which form to
output.)
Bug: 17897476
Change-Id: Iff85ceb6d52e8716251fab4e45d95a27184c5529
It turns out that appportable has a version that calls dlmalloc directly.
Re-add the dlmalloc symbol for 32 bit only as a compatibility shim that
calls malloc.
Bug: 17881362
(cherry pick commit from c9734d24d92f4737f5ab3808c77d816a1b084582)
Change-Id: Iee9a777f66a1edb407d7563a60792b767ac4f83a
It turns out that appportable has a version that calls dlmalloc directly.
Re-add the dlmalloc symbol for 32 bit only as a compatibility shim that
calls malloc.
Bug: 17881362
Change-Id: I8f20963b0b8d323489dc083e4063779e0d1d7447
This change should probably be made upstream as well, but they have a
note about not using it because it isn't available on all systems.
Change-Id: I6d8404c031bd2f486532ced55d94bbb4a4cd2e71
Use $(BUILD_SYSTEM)/base_rules to build it as custom module, so that
it's exposed to utilities like mm/mmma etc.
Bug: 17887283
Change-Id: Idd7b62d08e4d56331a3ff15da6aa46eae8c41898
The trouble with cp is that if you're running a command directly (because
you're using gdb, say), you need to make sure you've copied the linker
and shell again if you've done a rebuild that caused a change there.
Change-Id: I312da30c0f92b515967e854e0faba272c961ecc7
__open_2() is used by the fortify implementation of open(2) in
fcntl.h, and as such needs an unmangled C name. For some reason
(inlining?), this doesn't cause problems at the default optimization
level, but does for -O0.
The rest of these didn't cause build failures, but they look suspect
and probably will, we just haven't caught them yet.
(cherry-pick of 658727e111ed6dee7be5239494f0764f7b1b02f8 with conflicts
in stdio.h and string.h.)
Bug: 17784968
Change-Id: I7391a7a8999ee204eaf6abd14a3d5373ea419d5b
__open_2() is used by the fortify implementation of open(2) in
fcntl.h, and as such needs an unmangled C name. For some reason
(inlining?), this doesn't cause problems at the default optimization
level, but does for -O0.
The rest of these didn't cause build failures, but they look suspect
and probably will, we just haven't caught them yet.
Bug: 17784968
Change-Id: I7391a7a8999ee204eaf6abd14a3d5373ea419d5b
Otherwise the gcc compiler warning doesn't show up.
Add -Wno-error to fortify related tests. Fortify related tests
are expected to be examples of bad programs, and in many
cases shouldn't compile cleanly. Rewriting them to compile
cleanly isn't feasible nor desirable.
Bug: 17784968
(cherry picked from commit 1aaa17802c92d99ae170245c2b2f15a6c27b133e)
Change-Id: Ib6df1a3f44b55b1fff222e78395c10c51cd39817
