libandroid_support shouldn't be using Bionic's TLS slot. Add a
thread_local based implementation. We can't use the thread_local
implementation in bionic because the linker needs this and pthread
thread-locals (which is how thread_local is implemented) doesn't work
that early.
Test: make checkbuild
Test: adb shell /data/nativetest/bionic-unit-tests/bionic-unit-tests
Bug: https://github.com/android-ndk/ndk/issues/300
Change-Id: I7dcbf554ade2264d541d722fa3f86df04926e67a
Upstream's killpg is diverging further from glibc behavior, so let's just fork.
Bug: N/A
Test: ran tests
Change-Id: I70a3543018bc0a5c0bbf019ac527043b90568fda
Relocation packer no longer complains about missing
relocation sections.
Test: relocation-packer-unit-tests
Test: mm
Change-Id: I56814be326c15e046db1a96d14568d951f689ae2
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
If the hardware debug support is missing from the CPU, the kernel can
end up in the state where it reports that it supports N(>0) watchpoints,
but the "maximum supported watchpoint size" is zero.
This is not a really sensible API, but it is what we have. I'm going to
speak to folks upstream about whether we can have it report something
more sensible, but that will take a while (if ever).
So, for the time being, detect this situation and treat it as if no
hardware watchtpoints/breakpoints are supported.
Test: bionic-unit-tests --gtest_filter="sys_ptrace.*"
Change-Id: Id6a013c9bec8d8b450b4a36c28431f6b7fd15879
Bug: 63116544
Explicitly disables the integer_overflow sanitizer in the libm library.
This change should not impact any other build targets.
Bug: 30969751
Test: Built with and without SANITIZE_TARGET=integer_overflow
Change-Id: I98d0312344086b01394f456d4b953463b5e6cb1a
x86 needs the <sys/user.h> additions, x86-64 the <sys/procfs.h> ones.
Bug: N/A
Test: ndkports x86 and x86_64 binutils-2.28
Change-Id: I2e4738d3f8343d12db0536ca77045e2a0ccc6596
* TTYDEF_OFLAG referred to the BSD OXTABS constant instead of the Linux XTABS,
so references to it wouldn't compile.
* CEOL was incorrect (compared to `stty -a`).
* ttydefchars wouldn't compile (removed rather than attempt to fix something
of unclear utility).
Bug: http://b/63145226
Test: new test
Change-Id: I823e5eaab789cafd2eeea03f77ea553346822f74
We pretty much do these days. And apparently some GNU tools turn on obsolete
backwards-compatible behaviors otherwise.
Bug: http://b/63145226
Test: builds
Change-Id: I9a8af860768cc2c10548f172d1e8b4fba3e5115b
We've had <arpa/telnet.h> for years, despite being slightly more useless
than <arpa/ftp.h> and <arpa/tftp.h>. The inetutils package expects these
to be available.
Bug: http://b/63145226
Test: builds
Change-Id: I1e3c7421779e965b3342d681fefb8dc2561b604d
As in other places, only expose the constants at API levels where
we're also exposing the functions (to cope with "poor man's configure"
where an author assumes the presence of the #define to imply the
availability of the function).
Bug: http://b/63145226
Test: builds
Change-Id: I524f7288513aa6c35479c550e748a619397929b0
Before this change we have the old NDK inline termios functions with the
modern constants. Unfortunately the old NDK inline functions relied on
hacking the constants. Fix things by sharing the implementation between
the platform and the NDK headers.
Bug: https://github.com/android-ndk/ndk/issues/441
Test: ran tests
Change-Id: I2773634059530bc954167f29c4783413a2294d5a
<strings.h>'s ffs used to work by accident. In the past, <strings.h> used
to incorrectly declare ffs for all platforms at all API levels. In the
unified headers, there's no such declaration for x86 before API 18 (which
makes sense, because that function was missing on x86 until then).
But as long as there was a declaration for ffs, the compiler just inlined
__builtin_ffs. There was no problem at link time because the compiler didn't
actually add a reference to the missing ffs symbol.
Restore the old behavior by manually instructing the compiler to inline its
builtin in these cases.
Bug: https://github.com/android-ndk/ndk/issues/439
Test: built new NDK 'ffs' test
Change-Id: I840e99f237c86f7cb028a0f67aaa8c6ff3eda245
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
