GitLab

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

This time it's assembler.

Change-Id: Iae6369833b8046b8eda70238bb4ed0cae64269ea

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

Change-Id: If9d590e50265c61725d3673bd03796e65edd2d5e

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

Change-Id: I72bd1eb1d526dc59833e5bc3c636171f7f9545af

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

Give the compiler some hints that these error conditions
are unlikely to occur in practice.

Change-Id: Ifaf7322a12120ef663c8315c1a18c2dcbe4bda23

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

Avoid duplicating huge chunks of code.

Change-Id: Id6145cdfce781c5ffba2abaaa79681d25a7ab28f

Change-Id: Ib5067d51b983cac7760c975becce7fe2408ead04

I'll need at least one more pass, because there's some upstream code
lurking in libc/bionic, but this is still a step in the right direction.

Change-Id: I55927315972da8327ae01c5240ed587db17e8462

Add _FORTIFY_SOURCE support for snprintf, vsnprintf

At this time, we opt out of these protections for clang, as clang
does not implement __builtin_va_arg_pack().

http://clang.llvm.org/docs/UsersManual.html#c_unimpl_gcc

Change-Id: I73ebe5ec8dad1dca8898a76d6afb693a25f75375

Change-Id: I3bf4fa8678c33187cb8ce4b75e666ddcd24403ab

Add initial support for -D_FORTIFY_SOURCE to bionic for the
following functions:

* memcpy
* memmove
* strcpy
* strcat
* strncpy
* strncat

This change adds a new version of the above functions which passes
the size of the destination buffer to __builtin___*_chk.

If the compiler can determine, at compile time, that the destination
buffer is large enough, or the destination buffer can point to an object
of unknown size, then the check call is bypassed.

If the compiler can't make a compile time decision, then it calls
the __*_chk() function, which does a runtime buffer size check

These options are only enabled if the code is compiled with
-D_FORTIFY_SOURCE=1 or 2, and only when optimizations are enabled.

Please see
* http://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html
* http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html

for additional details on FORTIFY_SOURCE.

Testing: Compiled the entire Android tree with -D_FORTIFY_SOURCE=1,
and verified that everything appears to be working properly.
Also created a test buffer overflow, and verified that it was
caught by this change.

Change-Id: I4fddb445bafe92b16845b22458d72e6dedd24fbc

So that we can always get the full stack trace regardless of gcc's handling
of the "noreturn" attribute associated with abort().

(Cherry pick of Id264a5167e7cabbf11515fbc48f5469c527e34d4.)

Bug: 6455193

Conflicts:

	libc/Android.mk

Change-Id: I568fc5303fd1d747075ca933355f914122f94dac