File libc/SYSCALLS.TXT is updated to generate bionic's system call wrappers
for clock_gettime() & gettimeofday() that will be called if kernel vdso
implementations fail to execute.
The system call wrappers are generated using a python script gensyscalls.py.
Since all architectures support vdso now, there is no more need for conditional
statements regarding supported architectures in libc/bionic/vdso.cpp &
libc/private/bionic_vdso.h files.
Test: builds
Change-Id: I7213f29c179a7929851499d78a72900638ae861a
Signed-off-by: Goran Ferenc <goran.ferenc@imgtec.com>
Callers are supposed to #include <scsi/sg.h> but if we tell soong to add
bionic/libc/kernel/android/ to the include path, the uapi headers in there
would be (unintentionally) accessible as either <linux/name.h> or
<uapi/linux/name.h>.
Bug: N/A (hit while upgrading strace to 4.17)
Test: builds
Change-Id: I8d47dd51da688c38f747a255d401dfb2c209c805
The libmemunreachable code uses backtrace_string to print out the backtrace
information. However, when the offset of the map that a frame is in is
non-zero, no information is printed. This means that when a frame comes from
a shared library loaded from an apk, it's impossible to tell which
shared library the frame is really coming from.
Add the offset display when it's non-zero. This means this can now be fed
to development/scripts/stack to decode the frame.
Bug: 37276041
Test: Ran dumpsys meminfo --unreachable on an app that leaks from a
Test: shared library and verified the offset output is present.
Change-Id: I61d34ae3f617622d354cc099eff520a64782b6e2
The number of available physical pages is not constant and can
potentially change between calls to get_avphys_pages and
sysconf(_SC_AVPHYS_PAGES) calls.
Relax the assert to check that sconf(_SC_AVPHYS_PAGES) <= phys_pages.
Bug: http://b/31502852
Test: build and run bionic-unit-tests
Change-Id: Ibf8873d2151d93239391d2638dfbf055b70cde3a
Having
WARNING: DO NOT EDIT, AUTO-GENERATED CODE - SEE TOP FOR INSTRUCTIONS
every four lines made the headers harder to read, made the diffs much worse
each time we upgraded, and wasn't really providing any benefit. Before the
next uapi update, let's just stop doing this.
Bug: N/A
Test: builds, manually inspected files look right
Change-Id: Id7088cf750894c9d24950f3d53587fe3156c4f7d
There are a few instructions deprecated on armv8 that result in lots
of warnings. Add an arch directive so that these warnings go away.
This doesn't cause any problems because the instructions still
execute properly.
Bug: 38319728
Test: Built all of these assembler files and verified the warning are gone.
Change-Id: If063defdd16f290c01975233c8d257d1b2005e76
<sys/types.h> unconditionally includes <sys/sysmacros.h>.
<sys/sysmacros.h> defines major, minor, and makedev. In the deprecated NDK
headers, these were inline functions. In the unified headers, they are
function-like macros.
The inline functions would only collide with another function called major,
minor, or makedev but the macros will replace anything with a function-like
form such as definitions of class methods called major, minor, or makedev.
This causes code which has such definitions to fail to compile when moving
from the deprecated headers to the unified headers.
Resolve this by removing the transitive dependency. Folks who want
<sys/sysmacros.h> can ask for it explicitly (it's been in both bionic and
glibc for years, though I don't think macOS has it [as usual]).
Bug: https://github.com/android-ndk/ndk/issues/398
Test: builds
Change-Id: If2921c7b5d979c3066f199f22c64d4d2f7bf6632
Using __builtin_frame_address was clever, but didn't work for arm64 (for
reasons which were never investigated) and the ChromeOS folks claim it
causes trouble for x86 with ARC++ (though without a reproduceable test case).
Naked functions turn out to be quite unevenly supported: some architectures
do the right thing, others don't; some architectures warn, others don't (and
the warnings don't always match the platforms that _actually_ have problems).
Inline assembler also removes the guessing games: everyone knows what the
couple of instructions _ought_ to be, and now we don't have to reason about
what the compiler will actually do (yet still keep the majority of the code
in C).
Bug: N/A
Test: builds, boots
Change-Id: I14207ef50ca46b6eca273c3cb7509c311146a3ca
ETC did end up causing problems, since it's not per-arch. But
SHARED_LIBRARIES isn't correct either, since the build system tries to
read shared libraries as ELF files (to create the toc files).
NATIVE_TESTS is slightly better -- they are not libraries, so we don't
attempt to generate toc files, but they are considered per-arch.
Bug: 38463793
Test: Run CtsBionicTestCases
Change-Id: I01b4b093359e0c39eb2f8639d5c5dde9e304ed20
Some third-party code uses the existence of IN_CLOEXEC/IN_NONBLOCK to
detect the availability of inotify_init1. This is not correct, since
`syscall(__NR_inotify_init1, IN_CLOEXEC)` is still valid even if the C
library doesn't have that function, but for the time being we don't
want to harm adoption to the unified headers. We'll avoid defining
IN_CLOEXEC and IN_NONBLOCK if we don't have inotify_init1 for the time
being, and maybe revisit this later.
Test: make checkbuild
Bug: https://github.com/android-ndk/ndk/issues/394
Change-Id: Iefdc1662b21045de886c7ad1cbeba6241163d943
Some third-party code uses the existence of EPOLL_CLOEXEC to detect
the availability of epoll_create1. This is not correct, since having
up-to-date UAPI headers says nothing about the C library, but for the
time being we don't want to harm adoption to the unified headers.
We'll undef EPOLL_CLOEXEC if we don't have epoll_create1 for the time
being, and maybe revisit this later.
Test: make checkbuild
Bug: https://github.com/android-ndk/ndk/issues/302
Bug: https://github.com/android-ndk/ndk/issues/394
Change-Id: I8ee9ce62768fb174070ec51d114f477389befc4a
We've had pthread_*_setpshared for long enough that there are no
__INTRODUCED_IN guards.
Found because fio's configure script was confused by this.
Bug: N/A
Test: ran tests
Change-Id: I07b4d937741e4dcd7e615f2371b17c827341917a
Bug: 36401135
Test: Actually enable debug malloc and verify it loads properly.
Test: Ran unit tests.
Change-Id: I9df1699b06bb14c5df2c3cab35dc2eb0819033f1
This is a bit bogus because it's been removed from glibc (though not
thoroughly) and is never useful on Android (because the system calls
in question are compiled out of Android kernels, and SELinux would
disallow them even if you weren't running an Android kernel). This
also means that on glibc you need to include <linux/sem.h> for this
and on bionic you need <sys/sem.h> (and for either if you #include
the other file, you won't get this union).
Bug: https://github.com/android-ndk/ndk/issues/400
Test: added new test
Change-Id: I47f721da77515531f616d6ad8479bfbc9b60ee47
This change
- adds a query hook to android_net_context
- exposes relevant definitions to netd
- corrects a bug in query hooks' interaction with the cache
This change does not introduce any code to read the query hook
from the net context or make use of it.
Bug: 34953048
Test: Netd test suite passes
Change-Id: Ie091980e22ce9da07a3c4d387b371e544379d762
