History log of /bionic/libc/bionic/__vsprintf_chk.cpp
Revision Date Author Comments
e4c6b08c4e81f640afc502804d1226a3e79dc26d 19-Dec-2013 Nick Kralevich <nnk@google.com> Clean up more recursive FORTIFY_SOURCE calls

Don't use FORTIFY_SOURCE on functions which implement
FORTIFY_SOURCE, to avoid infinite recursion problems.

The previous patch only addressed one of the problems.

Bug: 12216860
Change-Id: I6f30ae7cb5b481be9942add18182ea4839d348a6
68b67113a44311b3568027af5893e316f63ec556 16-Oct-2013 Elliott Hughes <enh@google.com> 'Avoid confusing "read prevented write" log messages' 2.

This time it's assembler.

Change-Id: Iae6369833b8046b8eda70238bb4ed0cae64269ea
d1eda33f012e46083b91e087fb79d14a5ce70f0e 16-Oct-2013 Elliott Hughes <enh@google.com> Avoid confusing "read prevented write" log messages.

Moving to a "function: message" style avoids ambiguity.

Change-Id: If9d590e50265c61725d3673bd03796e65edd2d5e
eb847bc8666842a3cfc9c06e8458ad1abebebaf0 10-Oct-2013 Elliott Hughes <enh@google.com> Fix x86_64 build, clean up intermediate libraries.

The x86_64 build was failing because clone.S had a call to __thread_entry which
was being added to a different intermediate .a on the way to making libc.so,
and the linker couldn't guarantee statically that such a relocation would be
possible.

ld: error: out/target/product/generic_x86_64/obj/STATIC_LIBRARIES/libc_common_intermediates/libc_common.a(clone.o): requires dynamic R_X86_64_PC32 reloc against '__thread_entry' which may overflow at runtime; recompile with -fPIC

This patch addresses that by ensuring that the caller and callee end up in the
same intermediate .a. While I'm here, I've tried to clean up some of the mess
that led to this situation too. In particular, this removes libc/private/ from
the default include path (except for the DNS code), and splits out the DNS
code into its own library (since it's a weird special case of upstream NetBSD
code that's diverged so heavily it's unlikely ever to get back in sync).

There's more cleanup of the DNS situation possible, but this is definitely a
step in the right direction, and it's more than enough to get x86_64 building
cleanly.

Change-Id: I00425a7245b7a2573df16cc38798187d0729e7c4
6861c6f85e6563695c4763e56756398c9d5f6e14 04-Oct-2013 Nick Kralevich <nnk@google.com> Make error messages even better!

Change-Id: I72bd1eb1d526dc59833e5bc3c636171f7f9545af
e2617290fca2ebbc4d64cae5a8d8d9e9f8e6c701 04-Oct-2013 Nick Kralevich <nnk@google.com> FORTIFY_SOURCE: emphasize prevention in error messages.

FORTIFY_SOURCE prevents buffer overflows from occurring.
However, the error message often implies that we only
detect it, not prevent it.

Bring more clarity to the error messages by emphasizing
prevention over detection.

Change-Id: I5f3e1478673bdfc589e6cc4199fce8e52e197a24
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
326ea5413d18ea019cd1bda415ce428f7bdcafd2 04-Dec-2012 Nick Kralevich <nnk@google.com> clean up FORTIFY_SOURCE handling.

Avoid duplicating huge chunks of code.

Change-Id: Id6145cdfce781c5ffba2abaaa79681d25a7ab28f
4035b7a32155eac46f3f3782774deb5967ea2b54 23-Oct-2012 Elliott Hughes <enh@google.com> Move the FORTIFY_SOURCE helpers over to .cpp.

Change-Id: Ib5067d51b983cac7760c975becce7fe2408ead04