I've added some things like __ANDROID_MAJOR__ to an ndk-version.h, but
that is only in the NDK itself and so doesn't help the platform. Add
__ANDROID_NDK__ to identify that you're building for the NDK and not
the platform.
Test: make checkbuild
Bug: https://github.com/android-ndk/ndk/issues/407
Change-Id: I2d1f1c28e3764e4e658cf675b290b7a17253ee33
If _start_main is static, clang optimizes it out and then generates an
undefined reference from the inline assembler, so let's explicitly tell
the compiler it's used.
Bug: N/A
Test: ran tests
Change-Id: Iba3d9c63abae9a0dc32f236b01783515f0190956
As requested in the bug. This also rips __memcpy_chk out of memcpy.S,
which lets us cut down on copypasta (all of the implementations look
identical).
Bug: 12231437
Test: mma on aosp_{arm,arm64,mips,x86,x86_64} internal master;
checkbuild on bullhead internal master; CtsBionicTestCases on bullhead.
No new failures.
Change-Id: I88c39ca166bacde0b692aa3063e743bb046a5d2f
Enabling seccomp across all processes, rather than just zygote, is
useful for auditing the syscall usage of AOSP. Create a global seccomp
policy that can optionally be enabled by init.
Bug: 37960259
Test: confirm global seccomp by removing finit_module from policy and
observing modprobe fail, confirm regular seccomp unchanged by
comparing length of installed bpf
Change-Id: Iac53a42fa26a80b05126f262dd9525f4f66df558
AFAICT, all of these were added prior to the new-style FORTIFY going
in. Because clang saw two definitions of the "same" function, it got
upset. (e.g. 35d937e4eb)
Now that our FORTIFY functions are overloads of their library functions,
these undefs can be removed.
(This is a step toward making FORTIFY a library with -U_FORTIFY_SOURCE
on it, as requested in the bug.)
Bug: 12231437
Test: CtsBionicUnitTests. No new failures.
Change-Id: I844ff77106ee2bea72ae1cd0bb85d146939ecd05
It's not usable for cases where the off_t and off64_t functions became
available in different API levels, so it's not as big an improvement as
we'd hoped, but it cleans up several headers and should be usable for
any future additions (though recent Linux additions have _only_ supported
off64_t anyway).
Bug: N/A
Test: builds
Change-Id: I18b00f30666079d9d12d5b9c0ed916076d6c3641
Convenience macro for __RENAME if __USE_FILE_OFFSET64 mode. Lets us
avoid duplicating all the doxygen comments in frameworks headers.
Test: make checkbuild
Bug: https://github.com/android-ndk/ndk/issues/459
Change-Id: Ica44f22b2f1596e484694006c0926d94d16187b5
...by inlining them.
Also fix a couple of harmless bugs in passing. I've added tests, but in
both cases I don't think it was actually possible to hit the bad behavior:
we'd hit another test and fail immediately after in an externally
indistinguishable way.
Bug: N/A
Test: readelf
Change-Id: I8466050b0bfe2b7b94c76b383cf10c1d9d28debd
For the libandroid_support NOTICE file, we need to combine all the files
in that directory, plus the specific files pulled from bionic.
Also cleaned up some of the Python style.
Bug: N/A
Test: used for libandroid_support
Change-Id: If433e3a0f0478f06d99a9b3556e99dde06a7e5e1
Some of this code is used in the NDK libandroid_support now, as a static
library, so just being HIDDEN in the ELF sense isn't sufficient.
Rename digittoint to __libm_digittoint so we don't trample anyone's toes.
Also remove imprecise_powl and imprecise_tgammal. It turns out (to my
surprise) that we don't even have ld128 implementations of powl and tgammal,
so even LP64 was just using the "fake_long_double.c" hack in effect. Since
that's the case, let's *actually* do that because then we're not polluting
with the internal names in addition to the aliases.
Bug: N/A
Test: readelf
Change-Id: I273cc8fdc7ce53f9b8dfd4ef7796e358fe901837
We don't need these in libandroid_support, but we do need the other
parts of wchar.cpp, and they're not really related.
Test: make checkbuild
Bug: None
Change-Id: I40f3089b034abfd4873e81c0b6216a7cfd977d8d
Almost all of our w* functions come from FreeBSD already. The one downside is
that we can't take all our w* functions from FreeBSD because FreeBSD handles
locales very differently from us.
Bug: N/A
Test: ran tests
Change-Id: I177b4332499992babd5d5afe5b3f469f8c4345a5
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
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
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
