Apparently clang really doesn't want you to take the address of a builtin.
Since this is only a temporary hack, let's just shrug and accept that
clang-built volantis images won't work until we have new NVIDIA blobs.
Bug: http://b/20065774
Change-Id: I4c8e893b15a1af8f9c54d3f89bfef112b63d09b4
NVIDIA binary blobs are assuming that __cache_clear, _Unwind_Backtrace,
and _Unwind_GetIP are all in some library that they link, but now we've
cleaned up this leakage, they're no longer getting it. Deliberately leak
the symbols from libc.so until we get new blobs.
Bug: http://b/20065774
Change-Id: I92ef07b2bce8d1ad719bf40dab41d745cd6904d4
This flag allows to force loading of the library
in the case when for some reason multiple ELF files
share the same filename (because the already-loaded
library has been removed and overwritten, for example).
Change-Id: I798d44409ee13d63eaa75d685e99c4d028d2b0c1
If you pass in a negative value to gtest_repeat, it should run forever.
The new runner didn't allow this, now it does.
Change-Id: Ie0002c12e2fdad22b264adca37c165cfcfe05c7a
When the Android dynamic linker handles a text relocation,
it first relaxes the permissions on the segment being modified,
performs the modifications, and then restores the page permissions.
The relaxation worked by adding PROT_WRITE to whatever protection
bits were set in the section. In effect, the pages were getting set
to PROT_READ|PROT_WRITE|PROT_EXEC, modified, then restored to
PROT_READ|PROT_EXEC
The SELinux kernel code differentiates between 4 different kinds
of executable memory:
* Executable stack (execstack)
* Executable heap (execheap)
* File-based executable code which has been modified (execmod)
* All other executable memory (execmem)
The execmod capability is only triggered by the kernel when a
dirty but non-executable mmap()ed page becomes executable. When that
occurs, an SELinux policy check is done to see if the execmod capability
is provided by policy.
However, if the page is already executable, and PROT_WRITE is added
to the page, it's considered an execmem permission check, not an execmod
permission check.
There are certain circumstances where we may want to distinguish between
execmod and execmem. This change adjusts the dynamic linker to avoid
using RWX pages, so that an RX -> RW -> RX transition will properly
be detected as an execmod permission check instead of an execmem permission
check.
Bug: 20013628
Change-Id: I14d7be29170b156942f9809023f3b2fc1f37846c
This used to be handled by -fvisibility=hidden on libc_cxa, but that
was broken by the resolution of https://llvm.org/PR22419 (introduced
to Android in today's clang update).
Now we just use a version script that prevents these from being
re-exported from our shared libraries.
Change-Id: Ib290e1d0d7426e09ad17a91178162fff6dbdcfa9
stubs.cpp gets string.h inherited from private/android_filesystem_config.h
it should not rely on this in the future. The intent is to move fs_config
function into libcutils and thus deprecate any need for string.h in this
include file.
Change-Id: I946ec1979ef5bbb34fbcb4a99bf2cd79280bb2a3
