Some versions of kernel set AT_BASE to 0
if dynamic loader does not have PT_INTERP
set.
Bug: http://b/30739481
Test: run /system/bin/linker64 and /system/bin/linker
Change-Id: I1b67777166fe917d3ee1a97277045ca6f5db0084
Also, for the stuff that's also in <netinet/in.h> as real functions,
check that they're there too (and as functions rather than macros,
since that was historically not true).
Bug: http://b/28432448
Test: ran tests
Change-Id: I7e4ae926f7e02de3b6dd38d1953e5b3b43d44f74
__system_property_set sometimes produces broken_pipe error
when trying to write a property.
This change improves error messages and uses writev() instead
of sequence of send() calls.
Bug: http://b/35381074
Test: bionic-unit-tests --gtest_filter=prop*
Change-Id: I7a5b169c015db4e6b720370e58662de8206d1086
This tests for the presence of a kernel bug that meant that the kernel
would sometimes fail to report the watchpoint hit if the hardware
reported a address which did not exactly match the address range being
watched (which it is allowed to do per ARM spec if the instruction
accesses a larger block of memory than the region being watched). This
bug was fixed in linux kernel 4.9, and has been backported to older
android kernels.
Bug: 30802222
Bug: 30919905
Test: bionic-unit-tests --gtest_filter="sys_ptrace.*"
Change-Id: I80c35b29eaf28e2dbacb9e8ee5317fdea653fc87
Use struct stat::st_mtime instead of the underlying st_mtim, which is
called something different on Darwin.
Test: mma on linux, darwin
Change-Id: I2695a6c83ebb7d08ec56b1355e0f4bc0993a0acb
This seemed to be the only place in bionic where a fence on a
performance-critical path could be easily replaced by a stronger
load/store order constraint. Do so.
On x86 this should generate the same code either way. Based on
microbenchmarks of the relevant ARM instructions, this is currently
performance-neutral in this kind of context. But in the future, the
newly generated acquire loads should give us a performance benefit.
Test: Booted AOSP
Change-Id: I7823e11d6ae4fd58e0425244c293262e2320fd81
Running this periodically and checking in the results is not working
out, since the result is just that I'm having to spend a lot of time
cleaning up the headers every time I need to update them in the NDK.
Run the versioner as part of the build instead. This way bionic
header changes behave like the rest of the NDK headers and will
affect NDK builds in the platform *immediately*.
Remove the preupload hook for the versioner since it's part of the
normal build now.
The versioner's dependencies directory needs to be moved because
soong won't let us try to do things outside our module's directory
(in this case libc).
Unfortunately this means we need to build the versioner for Darwin,
because we now need it to perform a platform build.
Test: make checkbuild
Bug: None
Change-Id: Icdab8a962354d9e945072dc3f806baea376c8db4
Somewhat unsurprisingly, very few commands are happy to be run like this,
in particular multiplexed commands like toybox. But that's no reason for
the linker to get in the way too.
Bug: http://b/33276926
Test: new test
Change-Id: I6dd71ea0183f4da83571039c2198ebb6ed38520e
Thread local buffers were using pthread_setspecific for storage with
lazy initialization. pthread_setspecific shares TLS slots between the
linker and libc.so, so thread local buffers being initialized in a
different order between libc.so and the linker meant that bad things
would happen (manifesting as snprintf not working because the
locale was mangled)
Bug: http://b/20464031
Test: /data/nativetest64/bionic-unit-tests/bionic-unit-tests
everything passes
Test: /data/nativetest/bionic-unit-tests/bionic-unit-tests
thread_local tests are failing both before and after (KUSER_HELPERS?)
Test: /data/nativetest64/bionic-unit-tests-static/bionic-unit-tests-static
no additional failures
Change-Id: I9f445a77c6e86979f3fa49c4a5feecf6ec2b0c3f
The default locale is POSIX, not C.UTF-8. POSIX explicitly states
that MB_CUR_MAX is 1 for the POSIX locale:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdlib.h.html
Test: Made change in the NDK, built libc++ against it, ran NDK libc++
tests.
Bug: None
Change-Id: Ic2f6f96aa4a7f20d619030f41323831d01002715
So far this is the only issue we've hit in vendor code, and we've hit
it several times already. Rather than try to fix bullhead (the current
problem), let's just admit that the special case of 0 is a lot less
worrying.
Also fix the test expectations to correspond to the new abort message.
Bug: http://b/35455349 (crashes on 0)
Bug: http://b/35622944 (tests)
Test: ran tests
Change-Id: Iec57011fa699a954ebeaec151db2193e36d1ef35
1. There is no longer limit on property names - remove
the trimming the name of the property.
2. Make debug.ld work for processes with names ending with ":something"
This is naming convention for services:
https://developer.android.com/guide/components/services.html
Bug: http://b/35338922
Bug: http://b/33926793
Test: manual - set ld.debug.app property for the app
Test: from http://b/35338922 and see that it works
Test: for the service as well.
Change-Id: Ic7c6d4edce4a5a22f144496d5c0a3e458217c6e4
