1506fc178e9dcd873eaf95535ac7625ebb59388f |
|
18-Aug-2014 |
Dan Albert <danalbert@google.com> |
Expose android_set_abort_message(). Removes the leading underscores from __android_set_abort_message() and moves its declaration into a public header file. Bug: 17059126 Change-Id: I470c79db47ec783ea7a54b800f8b78ecbe7479ab (cherry picked from commit ce6b1abbb1da797e716d8ec03da4e3b6304fd11d) (cherry picked from commit 3a25ab952befbe908f6df45805683ebe3bf65863)
|
91570ce987ef93f9ba2fa663a5fee1bd2525a2ba |
|
10-Jul-2014 |
Elliott Hughes <enh@google.com> |
Slim down static binaries by avoiding stdio. It's okay for a program to choose to drag in stdio, but it's unfortunate if even the minimal "int main() { return 42; }" drags in stdio... This brings the minimal static binary on ARM down from 78KiB to 46KiB. Given that we don't have a separate -lpthread it's not obvious to me that we can shave this down any further. I'm not sure whether this is a worthwhile change for that reason. (And the fact that dynamic binaries, the usual case, are unaffected either way.) Change-Id: I02f91dcff37d14354314a30b72fed2563f431c88
|
ae0a62b014ece4bb9a0f8872738f58e7aec8378d |
|
08-May-2014 |
Elliott Hughes <enh@google.com> |
Fix LOG_ID_CRASH build failure. Change-Id: I66517e30c568d7f36f6bf6b1e4507ecf14f01226
|
c78368f04faa4ee17f546985809e7550f3f88636 |
|
07-May-2014 |
Elliott Hughes <enh@google.com> |
Change the interface for fatal logging. This more general interface lets liblog give us any fatal log message, regardless of source. This means we can remove the special case for LOG_ALWAYS_FATAL with a simpler scheme that automatically works for the VM too. Change-Id: Ia6dbf7c3dbabf223081bd5159294835d954bb067
|
2e3b7108b5b3d3f3a4a0fb369016e854bcf92212 |
|
23-Apr-2014 |
Elliott Hughes <enh@google.com> |
Allow liblog to pass failure reasons to debuggerd. assert(3) already does this, but LOG_ALWAYS_FATAL and LOG_ALWAYS_FATAL_IF have been missing out. Change-Id: I1d6214c4f792fa0d4ba3c14eded3fc9c332bd3c5
|
0336e35368aa161f1fed04ccde39553db4740b97 |
|
08-Nov-2013 |
Mark Salyzyn <salyzyn@google.com> |
libc: Make calls to new user-space logger * libc (fatal) logging now makes socket connection to the user-space logging service. * Add a TARGET_USES_LOGD make flag for BoardConfig.mk to manage whether logd is enabled for use or not. Change-Id: I96ab598c76d6eec86f9d0bc81094c1fb3fb0d9b4
|
59a13c122ebc4191583b67c846a95d690dcda5cf |
|
01-Aug-2013 |
Christopher Ferris <cferris@google.com> |
Optimize __memset_chk, __memcpy_chk. DO NOT MERGE. This change creates assembler versions of __memcpy_chk/__memset_chk that is implemented in the memcpy/memset assembler code. This change avoids an extra call to memcpy/memset, instead allowing a simple fall through to occur from the chk code into the body of the real implementation. Testing: - Ran the libc_test on __memcpy_chk/__memset_chk on all nexus devices. - Wrote a small test executable that has three calls to __memcpy_chk and three calls to __memset_chk. First call dest_len is length + 1. Second call dest_len is length. Third call dest_len is length - 1. Verified that the first two calls pass, and the third fails. Examined the logcat output on all nexus devices to verify that the fortify error message was sent properly. - I benchmarked the new __memcpy_chk and __memset_chk on all systems. For __memcpy_chk and large copies, the savings is relatively small (about 1%). For small copies, the savings is large on cortex-a15/krait devices (between 5% to 30%). For cortex-a9 and small copies, the speed up is present, but relatively small (about 3% to 5%). For __memset_chk and large copies, the savings is also small (about 1%). However, all processors show larger speed-ups on small copies (about 30% to 100%). Bug: 9293744 Merge from internal master. (cherry-picked from 7c860db0747f6276a6e43984d43f8fa5181ea936) Change-Id: I916ad305e4001269460ca6ebd38aaa0be8ac7f52
|
7c860db0747f6276a6e43984d43f8fa5181ea936 |
|
01-Aug-2013 |
Christopher Ferris <cferris@google.com> |
Optimize __memset_chk, __memcpy_chk. This change creates assembler versions of __memcpy_chk/__memset_chk that is implemented in the memcpy/memset assembler code. This change avoids an extra call to memcpy/memset, instead allowing a simple fall through to occur from the chk code into the body of the real implementation. Testing: - Ran the libc_test on __memcpy_chk/__memset_chk on all nexus devices. - Wrote a small test executable that has three calls to __memcpy_chk and three calls to __memset_chk. First call dest_len is length + 1. Second call dest_len is length. Third call dest_len is length - 1. Verified that the first two calls pass, and the third fails. Examined the logcat output on all nexus devices to verify that the fortify error message was sent properly. - I benchmarked the new __memcpy_chk and __memset_chk on all systems. For __memcpy_chk and large copies, the savings is relatively small (about 1%). For small copies, the savings is large on cortex-a15/krait devices (between 5% to 30%). For cortex-a9 and small copies, the speed up is present, but relatively small (about 3% to 5%). For __memset_chk and large copies, the savings is also small (about 1%). However, all processors show larger speed-ups on small copies (about 30% to 100%). Bug: 9293744 Change-Id: I8926d59fe2673e36e8a27629e02a7b7059ebbc98
|
61e699a133a4807fe878a6cb0d7190d7c96e21f8 |
|
12-Jun-2013 |
Elliott Hughes <enh@google.com> |
Clean up abort. * A dlmalloc usage error shouldn't call abort(3) because we want to cause a SIGSEGV by writing the address dlmalloc didn't like to an address the kernel won't like, so that debuggerd will dump the memory around the address that upset dlmalloc. * Switch to the simpler FreeBSD/NetBSD style of registering stdio cleanup. Hopefully this will let us simplify more of the stdio implementation. * Clear the stdio cleanup handler before we abort because of a dlmalloc corruption error. This fixes the reported bug, where we'd hang inside dlmalloc because the stdio cleanup reentered dlmalloc. Bug: 9301265 Change-Id: Ief31b389455d6876e5a68f0f5429567d37277dbc
|
cf870199d576bdfc339b7fb016c9f6fe7f2c87ed |
|
31-May-2013 |
Nick Kralevich <nnk@google.com> |
FORTIFY_SOURCE: strcat / strncat optimize __strcat_chk and __strncat_chk are slightly inefficient, because they end up traversing over the same memory region two times. This change optimizes __strcat_chk / __strncat_chk so they only access the memory once. Although I haven't benchmarked these changes, it should improve the performance of these functions. __strlen_chk - expose this function, even if -D_FORTIFY_SOURCE isn't defined. This is needed to compile libc itself without -D_FORTIFY_SOURCE. Change-Id: Id2c70dff55a276b47c59db27a03734d659f84b74
|
d04c18397946f87ac4495351537c31a3d67257da |
|
15-May-2013 |
Elliott Hughes <enh@google.com> |
Add more __restricts, clean up __format__ attributes. Change-Id: I7e2d270cc722d339d221eaea92747eaff3b51403
|
7b4d77e400d321ccc7cdadd1cd225ebb1a69d358 |
|
04-Apr-2013 |
Elliott Hughes <enh@google.com> |
Make abort messages available to debuggerd. This adds __libc_fatal, cleans up the internal logging code a bit more, and switches suitable callers over to __libc_fatal. In addition to logging, __libc_fatal stashes the message somewhere that the debuggerd signal handler can find it before calling abort. In the debuggerd signal handler, we pass this address to debuggerd so that it can come back with ptrace to read the message and present it to the user. Bug: 8531731 (cherry picked from commit 0d787c1fa18c6a1f29ef9840e28a68cf077be1de) Change-Id: I5daeeaa36c1fc23f7f437d73a19808d9d558dd4d
|
0d787c1fa18c6a1f29ef9840e28a68cf077be1de |
|
04-Apr-2013 |
Elliott Hughes <enh@google.com> |
Make abort messages available to debuggerd. This adds __libc_fatal, cleans up the internal logging code a bit more, and switches suitable callers over to __libc_fatal. In addition to logging, __libc_fatal stashes the message somewhere that the debuggerd signal handler can find it before calling abort. In the debuggerd signal handler, we pass this address to debuggerd so that it can come back with ptrace to read the message and present it to the user. Bug: 8531731 Change-Id: I416ec1da38a8a1b0d0a582ccd7c8aaa681ed4a29
|
8f2a5a0b40fc82126c691d5c30131d908772aab7 |
|
15-Mar-2013 |
Elliott Hughes <enh@google.com> |
Clean up internal libc logging. We only need one logging API, and I prefer the one that does no allocation and is thus safe to use in any context. Also use O_CLOEXEC when opening the /dev/log files. Move everything logging-related into one header file. Change-Id: Ic1e3ea8e9b910dc29df351bff6c0aa4db26fbb58
|