Previously, the linker always loaded itself into the same
location in memory, which inhibited the effectiveness of Android's
ASLR implementation. Modify the linker code so it can be relocatable
and link itself at runtime.
Change-Id: Ia80273d7a00ff648b4da545f4b69debee6343968
Use LOCAL_NO_CRT to prevent linking against crtbegin.o, rather than
messing with build rules. This also prevents linking against crtend.o,
which isn't needed for the linker.
Change-Id: I0c5b9999be7e8676560fe145c1c033ffce8db4d1
The computation of si->base assumed that the first entry in the
program header table is a PT_PHDR. This results in the dynamic
linker crashing with a SIGSEGV/MAPERR when trying to load some
of the NDK unit test programs, which happen to have an EXIDX
header first, followed byu a PHDR one.
This patch fixes the computation by parsing the program header
table, looking explicitely for the PHDR entry. This fixes the
load of the NDK unit test programs, and doesn't affect system
libraries.
Change-Id: Id18ea6037dbe950b5abbbce816c2960321f0b81d
Modify the dynamic linker so that executables can be loaded
at locations other than 0x00000000.
Modify crtbegin* so that non-PIC compilant "thumb interwork
veneers" are not created by the linker.
Bug: 5323301
Change-Id: Iece0272e2b708c79034f302c20160e1fe9029588
Some SoCs that support NEON nevertheless perform better with a non-NEON than a
NEON memcpy(). This patch adds build variable ARCH_ARM_USE_NON_NEON_MEMCPY,
which can be set in BoardConfig.mk. When ARCH_ARM_USE_NON_NEON_MEMCPY is
defined, we compile in the non-NEON optimized memcpy() even if the SoC supports
NEON.
Change-Id: Ia0e5bee6bad5880ffc5ff8f34a1382d567546cf9
Currently the dlmalloc allocates the memory with 8-byte alignment.
According to the com.aurorasoftworks.quadrant.ui.professional benchmark data:
We can get much better memory performance if we change it to be 16-byte aligned.
For example, On Nexus-S:
8-byte aligned :
1378 1070 1142 1665 1765 1163 1179 1263 1404 avg: 1336.555555556
16-byte aligned:
1691 1731 1780 1691 1671 1678 1802 1758 1780 avg: 1731.333333333
gain: 29.53%
That patch provides flexibity to customize the MALLOC_ALIGNMENT from the
board config.The macro MALLOC_ALIGNMENT defaults to 8.
To change it, please define BOARD_MALLOC_ALIGNMENT in the BoardConfig.mk:
BOARD_MALLOC_ALIGNMENT := <whatever>
Change-Id: I8da0376944a0bbcef1d0fc026bfb6d9125db9739
Signed-off-by: Jin Wei <wei.a.jin@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Beare, Bruce J <bruce.j.beare@intel.com>
A call to pthread_key_delete() after pthread_exit() have unmapped the stack of a thread
but before the ongoing pthread_join() have finished executing will result in an access
to unmapped memory.
Avoid this by invalidating the stack_base and tls pointers during pthread_exit().
This is based on the investigation and proprosed solution by
Srinavasa Nagaraju <srinavasa.x.nagaraju@sonyericsson.com>
Change-Id: I145fb5d57930e91b00f1609d7b2cd16a55d5b3a9
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
So that we can always get the full stack trace regardless of gcc's handling
of the "noreturn" attribute associated with abort().
[cherry-picked from master]
BUG:6455193
Change-Id: I0102355f5bf20e636d3feab9d1424495f38e39e2
Signed-off-by: Liubov Dmitrieva <liubov.dmitrieva@intel.com>
Signed-off-by: H.J. Lu <hongjiu.lu@intel.com>
Signed-off-by: Wei A Jin <wei.a.jin@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Conflicts:
libc/arch-x86/string/ssse3-memcpy5.S
Change-Id: I41e70d1d19d5457e65c89b64da452fbdaf3a00a7
The creation of a thread succeeds even if the requested scheduling
parameters can not be set. This is not POSIX compliant, and even
worse, it leads to a wrong behavior. Let pthread_create() fail in this
case.
Change-Id: Ice66e2a720975c6bde9fe86c2cf8f649533a169c
Signed-off-by: Christian Bejram <christian.bejram@stericsson.com>
