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
(cherry picked from commit 9afb2f2106a5d659854c175c574c1c31e0e205a2)
Change-Id: I92c331ef6fb5868af49e75bc595710d290a95f5b
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
__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
This library calls pthread_mutex_lock and pthread_mutex_unlock with a NULL
pthread_mutex_t*. This gives them (and their users) one release to fix things.
Bug: 17443936
(cherry picked from commit 7d3f553f989f830976efa92ddc3c84661d4d42aa)
Change-Id: Ie26bbecd3a74d61113b51c18832872499b97ee86
(cherry picked from commit b5e7eba6d1b97e471996fcfe7dbde7cbba7512ef)
This library calls pthread_mutex_lock and pthread_mutex_unlock with a NULL
pthread_mutex_t*. This gives them (and their users) one release to fix things.
Bug: 17443936
(cherry picked from commit 7d3f553f989f830976efa92ddc3c84661d4d42aa)
Change-Id: Ie26bbecd3a74d61113b51c18832872499b97ee86
This library calls pthread_mutex_lock and pthread_mutex_unlock with a NULL
pthread_mutex_t*. This gives them (and their users) one release to fix things.
Bug: 17443936
Change-Id: I3b63c9a3dd63db0833f21073e323b3236a13b47a
Fix and use __RENAME (and lose ___RENAME --- two underscores should be
enough for anybody). This was the point of this change, because I want
to use __RENAME to support the two basename variants and the two
strerror_r variants.
Lose a bunch of macros that weren't being used.
Lose three dead files from the DNS code.
Bug: 17784968
(cherry picked from commit 2cfb4e8e2e217ef0e4140dcbf9b3da809781158c)
Change-Id: I5e96146f92c0521248c78c0933bec5e9a9818222
At -O0, the attribute warning on sprintf is actually triggered (why
doesn't this happen with -Os?!) and promoted to an error by -Werror.
asctime64_r() is a non-standard function, but the IBM docs state that
the buffer is assumed to be at least 26 characters wide, and the
format string does limit to that (assuming a 4 digit year, also
defined by the IBM docs).
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxbd00/asctimer.htm
Change-Id: I1c884474a769aa16c53e985c3d8d694c478c1189
For silvermont, the __popcountsi2 symbol does not get exported by libc.
But for atom, this symbol is exported. Since we already exported this symbol
for previous releases, it's better to just follow through and force
the export, but only for 32 bit. x86 64 bit will not export this symbol.
Bug: 17681440
(cherry picked from commit d11eac3455a059a092ceee92eda9905e1d661e94)
Change-Id: I93704c721d98d569922f606f214069bda24872ba
For silvermont, the __popcountsi2 symbol does not get exported by libc.
But for atom, this symbol is exported. Since we already exported this symbol
for previous releases, it's better to just follow through and force
the export, but only for 32 bit. x86 64 bit will not export this symbol.
Bug: 17681440
Change-Id: I6c62245f0960910f64baaaf6d9d090bf3ea5f435
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
Change-Id: I93bececa7444d965f18c7c27d46e7abce5c49a02
