We had several bugs filed saying "if I set _FILE_OFFSET_BITS=64 when
targeting an API < L, various functions are missing". Instead of
saying "yes, they are", we quietly just modified the header files to
expose the non-64-bit variants. This makes no sense. We can't just say
"oh, yeah, we don't have a version of this function that agrees with
your calling code about how large off_t is, but here's a version that
doesn't: I'm sure it'll be fine".
_FILE_OFFSET_BITS=64 on Android LP32 has always been a game of chance,
but that game should be "are all the functions my code needs available
at compile time?", not "will my code actually work at run time?".
Bug: https://github.com/android-ndk/ndk/issues/449
Bug: https://github.com/android-ndk/ndk/issues/442
Bug: https://github.com/android-ndk/ndk/issues/333
Bug: https://github.com/android-ndk/ndk/issues/332
Bug: https://github.com/android-ndk/ndk/issues/324
Test: builds
Change-Id: Ib095251d3e21e77ed50cc3575388107fecec4ecd
Rather than do this in libandroid_support, we may as well just stick it with
the other historical stdlib workarounds in bionic itself...
Bug: N/A
Test: built new NDK test
Change-Id: Ia5cf4010581eb79d4adf924e87d0bc050b9e2839
These still won't get guards added by the preprocessor, because it
compiles with C-only.
Bug: https://github.com/android-ndk/ndk/issues/440
Test: treehugger
Change-Id: I893b345e528ed1b761e0db00700037411bbb8b78
This reverts commit ae735163e5.
QA claims this causes:
AndroidRuntime: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.media.MediaPlayer.setSurface(android.view.Surface)' on a null object reference
AndroidRuntime: at com.android.setupwizardlib....
Bug: http://b/63141434
Change-Id: I05a6849471623d4cde8b254b1020b0ccbd84b699
Warnings:
bionic/libc/bionic/fts.c:722:5: warning: Null passed to a callee that
requires a non-null 1st parameter
bionic/libc/bionic/sched_cpualloc.c:34:25: warning: Result of 'malloc'
is converted to a pointer of type 'cpu_set_t', which is incompatible
with sizeof operand type 'unsigned long'
bionic/linker/linker_main.cpp:315:7: warning: Access to field 'e_type'
results in a dereference of a null pointer (loaded from variable
'elf_hdr')
bionic/linker/linker_main.cpp:493:66: warning: Access to field 'e_phoff'
results in a dereference of a null pointer (loaded from variable
'elf_hdr')
bionic/linker/linker_main.cpp:90:14: warning: Access to field 'next'
results in a dereference of a null pointer (loaded from variable 'prev')
Bug: None
Test: mma; analyzer warnings are gone. CtsBionicTestCases pass.
Change-Id: I699a60c2c6f64c50b9ea06848a680c98a8abb44a
Starting from Linux 4.7, arm64's defconfig enables 48-bit VAs, see:
https://git.kernel.org/torvalds/c/211102d8
On arm64, the CFI shadow configuration currently assumes that VAs
are 39-bit long, and as expected this results in a segfault on a
(defconfig) 4.7+ kernel, when linking a CFI-enabled library.
Consequently, this change increases the max target address to
account for the new max VA size.
Change-Id: I3fb808563fa77a457c65e9663da0613117332072
This seccomp failure is in the fault handler:
05-25 12:03:25.042 10201 27425 27425 F DEBUG : backtrace:
05-25 12:03:25.042 10201 27425 27425 F DEBUG : #00 pc 00015380
/data/data/redacted/files/storage/lib/libcrashsdk.so
So whenever an app using this crash sdk crashes it looks like a seccomp
problem. Fixing this won't stop the apps crashing, but will make the
crash reports accurate and useful.
So yes, the bug below is already fixed, but this issue has come back 2
or 3 times with different apps (latest is b/62874867). This change
doesn't fix that crash either, but again it improves the reporting.
Bug: 62090571
Test: Device boots, app still fails but no longer with SECCOMP error
Change-Id: Ie0f8dc965001c8bc43f6a545b35bdcd38f006213
__libc_preinit sets up the stack protector global cookie value, and thus
cannot intialize a stack protector cookie for itself in the function
prologue. LTO compilation can inline functions requiring a stack
protector into __libc_preinit. This patch disables stack protection for
__libc_preinit and forces all potentially inlined functions into a
helper that can have a stack protector.
Test: run bionic-unit-tests
Change-Id: I45911611190f216c91eb6feff722967214c5f99f
No-one cares about seeing "async_safe_fatal" (which you have to admit is a
pretty confusing name for an app developer anyway).
On arm:
#00 pc 0001a43c /system/lib/libc.so (abort+63)
#01 pc 0001a627 /system/lib/libc.so (__assert+14)
And aarch64:
#00 pc 000000000001d75c /system/lib64/libc.so (abort+120)
#01 pc 000000000001dad0 /system/lib64/libc.so (__assert+44)
Bug: N/A
Test: ran `crasher assert` and `crasher64 assert`
Change-Id: I00be71c566c74cdb00f8e95d634777155bc3da03
With this, stack frame 0 is the abort, not tgkill.
arm:
#00 pc 0001a41c /system/lib/libc.so (abort+63)
arm64:
#00 pc 000000000001d75c /system/lib64/libc.so (abort+120)
Also "include what you use" for <sys/syscall.h>.
Bug: N/A
Test: ran `crasher abort` and `crasher64 abort`
Change-Id: I6517ac67b39b4133e890d52efc115071c812958b
linker_config#smoke and linker_config.asan_smoke are trying to find
paths under the /vendor directory. If there is no vendor partition,
the real path of them is started with /system/vendor.
This CL allows those paths in the tests by getting the resolved paths
for systems without a vendor partition.
Bug: http://b/62562515
Test: linker_config_test passes without a vendor partition.
Change-Id: Id6d16ef623efd81ab9083c3e819da2ad22a28bf8
This is no longer used in the platform, and shouldn't be used in NDK. Apps
should use the NDK's cpu-features module, which supports (a) more specific
queries and (b) all Android architectures, not just 32-bit ARM.
Bug: http://b/18556103
Test: builds
Change-Id: I544ef267a6d7d887223186180c77d9ad0321e605
Building ruby actually trips over both of these:
* if the RTLD_ constants aren't #defined, it uses its own incorrect values.
* if the REG_ constants aren't #defined, it confuses x86 with x86-64.
In all other places where we have enums in our headers, we already match
existing glibc practice.
Bug: http://b/62531921
Test: builds
Change-Id: I5b3aab25a1a24611bdc58f2eda4104a78e9f841c
Move all tests into stdlib_test.cpp since that's where the definition lives
in bionic.
Add a sweep test and a various size test.
Test: Run new unit tests on glibc and angler.
Change-Id: Ief1301f402bea82ce90240500dd6a01636dbdbae
No other C library expose these, and I couldn't find any callers.
Bug: http://b/62531921
Test: builds
Change-Id: I4a3505bc0897286a4036c48066b98d16665b573a
fstat64/fstatat64/_flush_cache were accidentally put in SYSCALLS.TXT in:
https://android-review.googlesource.com/#/c/390454/
This patch just moves them to SECCOMP_WHITELIST.TXT because we do not
want stubs accidenatally generated for the mentioned syscalls using
gensyscalls.py script.
This commit does not introduce any functional changes to mips64_policy.cpp.
Test: Run genseccomp.py -> File seccomp/mips64_policy.cpp not changed.
Test: Run gensyscalls.py -> INFO:root:no changes detected!
Change-Id: I3b527b3d9f18715c44a4e6ddc6db6e49f48f4890
Signed-off-by: Miodrag Dinic <miodrag.dinic@imgtec.com>
In a similar style to some of our other "not really, but enough" headers
like <sys/vt.h>.
Bug: N/A
Test: build GNU dd or BSD dd with a standalone toolchain
Change-Id: I8fbd1aac1d97e24b05e7aae8a55666300b5bf1ed
