memmove: Don't call memcpy if regions overlap

memmove() unconditionally calls memcpy() if "dst" < "src". For
example, in the code below, memmove() would end up calling memcpy(),
even though the regions of memory overlap.

int main() {
  char buf3[0x800];
  char *dst  = &buf3[1];
  char *src = &buf3[0x400];
  memset(buf3, 0, sizeof(buf3));
  memmove(dst, src, 0x400);
  printf("1: %s\n", buf3);
  return 0;
}

Calling memcpy() on overlaping regions only works if you assume
that memcpy() copies from start to finish. On some architectures,
it's more efficient to call memcpy() from finish to start.

This is also triggering a failure in some of my code.

More reading:
* http://lwn.net/Articles/414467/
* https://bugzilla.redhat.com/show_bug.cgi?id=638477#c31 (comment 31)

Change-Id: I65a51ae3a52dd4af335fe5c278056b8c2cbd8948
Cherry-pick "generate PIC code".

Change-Id: I7d5f2e5663df263493f65e364c959e663fc4d13a
Remove the last references to SuperH.

Change-Id: Icb44c1f94cb178d90b4c2b1e8f6d175586aec4e1
bionic: add clean kernel header ucontext.h

Change-Id: I34fd0b0147fa33fd74c13480bc11827634233a41
Give the timer_create SIGEV_THREAD helper threads sensible names.

Bug: 6609676
Change-Id: I286b197c75beee4d9930b0973f2d7dd47c14e91c
Define __stack_chk_fail_local.S

With -fstack-protector, x86 -m32 needs __stack_chk_fail_local
defined in crtbegin_*.o.

Include __stack_chk_fail_local.S in begin.S otherwise linker
(which is built w/o crt*) may not link.

Change-Id: Id242fcf3eff157264afe3b04f27288ab7991220a
bionic: fix NULL parameter failure in getcwd()

LTP: getcwd01 failed in LTP

Need to check getcwd parameters, otherwise it will lead to
posix test case to fail.

Change-Id: Ieb673b6dd4ca6481da81c5339dbf7ec0a463f263
Signed-off-by: Jin Wei <wei.a.jin@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
libc/x86: ensure the stack 16-byte aligned when tasks created

Currently Renderscript sample code RsBalls crashed on x86 when SSE2
enabled. The root cause is that the stack was not 16-byte aligned
from the beginning when the processes/threads were created, so the
RsBalls crashed when SSE2 instructions tried to access the variables
on the stack.

- For the thread created by fork():
Its stack alignment is determined by crtbegin_{dynamic, static}.S

- For the thread created by pthread_create():
Its stack alignment is determined by clone.S. __thread_entry( ) is
a standard C function. In order to have its stack be aligned with
16 byte properly, __thread_entry() needs the stack with following
layout when it is called:
layout #1 (correct)
--------------
|            |
-------------- <--ESP (ECX - 20)
| ret EIP    |
-------------- <--ECX - 16
| arg0       |
-------------- <--ECX - 12
| arg1       |
-------------- <--ECX - 8
| arg2       |
-------------- <--ECX - 4
| unused     |
-------------- <--ECX (16-byte boundary)

But it has following layout for now:
layout #2: (incorrect)
--------------
|            |
-------------- <--ESP (ECX - 16)
| unused     |
-------------- <--ECX - 12
| arg0       |
-------------- <--ECX - 8
| arg1       |
-------------- <--ECX - 4
| arg2       |
-------------- <--ECX (16-byte boundary)

Fixed in this patch.

Change-Id: Ibe01f64db14be14033c505d854c73033556ddaa8
Signed-off-by: Michael Liao <michael.liao@intel.com>
Signed-off-by: H.J. Lu <hongjiu.lu@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Eliminate duplicate constants

include/elf.h contains basically the same values as
linux/auxvec.h. Eliminate dups.

include/sys/exec_elf.h contains basically the same
values as linux/elf.h. Eliminate dups.

Change-Id: I66b8358161bb52223bb657f8f73ba28b324f4fa3
update stddef.h

Pull in an updated version of stddef.h from the linux kernel.
Pulled from upstream kernel at 891003abb0db6bfffd61b76ad0ed39bb7c3db8e1

This file was generated using the following command:

cd bionic/libc/kernel/
./tools/clean_header.py -u ../../../external/kernel-headers/original/linux/stddef.h

Change-Id: I6c29f3fa100c5368da41d0f0da39bc50fa668e9d
libm: cherry-pick one patch from freebsd to fix logb() denormals issue

from http://svnweb.freebsd.org/base?view=revision&revision=176101
"
Oops, fix the fix in rev.1.10.  logb() and logbf() were broken on
 denormals, and logb() remained broken after 1.10 because the fix for
 logbf() was incompletely translated.

Convert to __FBSDID().
"

Change-Id: I54f33648db7c421b06eee1ea8e63c57a179fae0d
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Jin Wei <wei.a.jin@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
libc: Define new symbol visibility macros

This patch defines a few new macros that can be used to control the
visibility of symbols exported by the C library:

- ENTRY_PRIVATE() can be used in assembly sources to indicate
  that an assembler function should have "hidden" visibility, i.e.
  will never be exported by the C library's shared library.

  This is the equivalent of using __LIBC_HIDDEN__ for a C function,
  but ENTRY_PRIVATE() works like ENTRY(), and must be used with
  END() to tag the end of the function.

- __LIBC_ABI_PUBLIC__ can be used to tag a C functions as being
  part of the C library's public ABI. This is important for a
  few functions that must be exposed by the NDK to maintain
  binary compatibility.

  Once a symbol has been tagged with this macro, it shall
  *never* be removed from the library, even if it becomes
  directly unused due to implementation changes
  (e.g. __is_threaded).

- __LIBC_ABI_PRIVATE__ can be used for C functions that should
  always be exported by the C library because they are used by
  other libraries in the platform, but should not be exposed
  by the NDK. It is possible to remove such symbols from the
  implementation if all callers are also modified.

+ Add missing END() assembly macro for x86

Change-Id: Ia96236ea0dbec41d57bea634b39d246b30e5e234
Make sure __u64 is defined even for strict ansi or -std=c99

The x86 asm headers define __u64 regardless of __STRICT_ANSI__.
The linux/videodev2.h header requires __u64 to be defined, thus
this fixes compiling with -std=c99 when including the
linux/videodev2.h header.

In glibc, the asm/types.h header defines __u64 regardless of
__STRICT_ANSI__.

This is the change for the generated arch-arm/asm/types.h
header, as produced by the update_all.py script (without all
the other unrelated changes that the script produces).

FWIW, the same issue also is present in
arch-sh/asm/types.h, but there are no source headers for
arch-sh in external/kernel-headers (and regenerating the
headers simply removes that file).

Change-Id: If05fcc9ed6ff5943602be121c7be140116e361fe