History log of /bionic/libc/private/libc_logging.h
Revision Date Author Comments
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