In particular this affects assert(3) and __cxa_pure_virtual, both of
which have managed to confuse people this week by apparently aborting
without reason. (Because stderr goes nowhere, normally.)
Bug: 6852995
Bug: 6840813
Change-Id: I7f5d17d5ddda439e217b7932096702dc013b9142
So that we can always get the full stack trace regardless of gcc's handling
of the "noreturn" attribute associated with abort().
BUG:6455193
Change-Id: Id264a5167e7cabbf11515fbc48f5469c527e34d4
Ideally __libc_android_abort would be static, but it could not be
because gcc would not allow calling a static function from an asm
statement. Instead, using GCC visibility is work around.
Change-Id: Ifff6b9957ca3f0fc03c75c3e42582a48d43cefa2
The code generated for Thumb and Thumb2 targets has different handling
for abort(). Because abort() is "noreturn", it doesn't need to preserve
the callee-save registers. The Thumb2 version trashes LR and makes it
impossible to figure out who called abort().
This inserts a trivial stub function; net effect is stack traces are
reasonable after an abort().
For bug 2191452.
the issue here is that abort() can be called from anywhere, in particular
from malloc or free. When we try to use the debug_log functions, these
can end up calling into some code (like malloc/free) that called abort()
in the first place and end up in an infinite recursion loop.
