We had the NetBSD __CONCAT macro, despite the fact that our only callers
are FreeBSD code. The FreeBSD libm changes in FreeBSD r336665 require
the FreeBSD implementation rather than the NetBSD one.
Unfortunately for me, that libm code is built in the NDK build too,
where it's built against the NDK's <sys/cdefs.h>. So I need to update
__CONCAT first before I can update the libm code.
Bug: http://b/111710419
Test: ran tests
Change-Id: I70e76e4caab2929c939bfb7009df9fe79d26806a
This reverts commit 067bdc9546.
The angler/bullhead builds still use GCC, so I'll wait until they're turned down.
Bug: https://issuetracker.google.com/74404306
Change-Id: I777b08dd6ab5250d532b4b5cc56e9a790c13db20
NDK r18 (which removes GCC) is about to ship. We don't need this any more.
The immediate motivation for removing this right now is that the test
fails whenever we add Clang-only flags to the build system.
While we're here, clean up <stdatomic.h> too.
Bug: https://issuetracker.google.com/74404306
Test: ran tests
Change-Id: Iaad5d634d1ba76f0b6f19ad32cc27b2533771a4a
When compiling on/for at least Lollipop, always use the fortified
versions of FD_X macros. This works around side-effect issues (which
are explicitly called out in the specification) and generally
increases robustness of code.
Bug: 77986327
Test: mmma bionic
Test: m
Test: bionic_unit_tests
Change-Id: I9096c6872770e46ba5ab64e7375ff83fc0518e07
This also tweaks cdefs to make __overloadable usable outside of
FORTIFY. It had to be FORTIFY-only before we had unmarked overload
support in clang+Bionic.
Bug: https://github.com/android-ndk/ndk/issues/402
Test: Internal master builds + `mma`. `mma` in Bionic fails if the
change to ioctl is undone.
Change-Id: Ib386b1786e1dca625e6d5a18682005adc734d9c1
Added to each ucontext_t for source compatibility between platforms where
sigset_t and sigset64_t differ (arm, x86) and where they're the same
(all the rest).
Bug: http://b/72493232
Test: ran tests
Change-Id: I65a37bfa177933701bbe6c2350448885fd0f9c43
Caused problems for some Google source switching to unified headers
because the legacy headers just used #define instead.
Bug: http://b/73210428
Test: builds
Change-Id: If8a36f284031e57af419903610029a8c34a23d91
Now that we have a clang that supports transparent overloads, we can
kill all of this cruft, and restore our upstream sources to their
untouched glory. Woohoo!
Bug: 12231437
Test: Built aosp_marlin; no obvious patch-related aosp_mips issues.
Change-Id: I520a19d014f12137f80e43f973dccd6711c571cd
This doesn't address `struct sigaction` and `sigaction`. That will
come later.
Bug: http://b/72493232
Test: ran tests
Change-Id: I4134346757ce3a4dac6feae413361cec16223386
The history has no motivation for <asm/termbits.h>, and other C libraries
don't seem to include any of the extra types and constants that gains us.
This caused problems building FFMPEG, which defines its own B0.
Bug: https://github.com/android-ndk/ndk/issues/630
Test: builds
Change-Id: If032b9fa7860777c13f7bd8e68fb78ff606dcd94
* Variadic functions usually cannot be inlined.
* Do not use misleading __always_inline attribute,
and also avoid early clang 7.0 compiler bug.
Bug: 72412382
Test: build and boot aosp*-eng in emulator
Change-Id: I7490976166581abc626f397ad408581ada0ed308
This adds a new mechanism to say "replace struct S with #include <bits/S.h>".
Also switch epoll_event over to the new mechanism.
Also use the kernel's struct sockaddr_storage directly rather than behind
an unnecessary #define.
This patch also removes some dead code in the header scrubber. This code
still needs rewriting completely. I learned that a "block" isn't necessarily
a single struct definition, say; it might be a run of them. It seems like
a block is a run of preprocessor directives or a run of regular code.
Bug: https://issuetracker.google.com/36987220
Test: new test
Change-Id: Ic6a5c09559766a4babe3cd4c3ea538b885e07308
And fix one thing that this found: apparently <stdlib.h> should also
make the various *WAIT* macros available.
Bug: N/A
Test: builds
Change-Id: Id879bf3c1bddd1170261a809e7280150a74d6b3d
We're still seeing lots of confusion. People do seem to look as far as
the headers, but stop there. So let's try a bit harder to point them in
the right direction.
Also explicitly state that removing _FILE_OFFSET_BITS=64 is the
behavior-preserving fix for compilation problems when upgrading to NDK
r15 or later.
Bug: N/A
Test: N/A
Change-Id: I2d5c65b2fb5cccb9977901e51fea1ad2ccc0fd95
Having FORTIFY enabled for clang-tidy adds no value, and breaks some
heuristics for recognizing standard library functions (see the bug).
This also disables FORTIFY for the static analyzer (which we use
through clang-tidy), because it presumably tries to recognize standard
library functions through similar heuristics.
Bug: 36664104
Test: mma with and without the patch to cdefs. New test breaks without.
Change-Id: I40c66ff9e638b306878ada006bc2c98f2346e77a
Autosubmit fired before the CL was actually ready (forgot to hit "y"
on the repo upload).
Test: make checkbuild
Test: copied into the NDK and ran mmap64_fob64 test.
Bug: lots
Change-Id: I8c0400a703f319e8e230f7ba9178009ed7c88be0
While this was never an inline, this function alone has caused most of
the bug reports related to _FILE_OFFSET_BITS=64. Providing an inline
for it should allow a lot more code to build with _FILE_OFFSET_BITS=64
when targeting pre-L.
Test: make checkbuild
Test: built trivial cc_binary for LP32 against API 14 with
_FILE_OFFSET_BITS=64 set
Bug: lots
Change-Id: I8479d34af4da358c11423bee43d45b59e9d4143e
iOS 10 has <sys/random.h> with getentropy, glibc >= 2.25 has
<sys/random.h> with getentropy and getrandom. (glibc also pollutes
<unistd.h>, but that seems like a bad idea.)
Also, all supported devices now have kernels with the getrandom system
call.
We've had these available internally for a while, but it seems like the
time is ripe to expose them.
Bug: http://b/67014255
Test: ran tests
Change-Id: I76dde1e3a2d0bc82777eea437ac193f96964f138
We can cut a lot of stuff out of the NDK's libandroid_support with this,
and reduce unnecessary relocations for all LP32 code. LP64 code should
be unaffected.
Bug: https://issuetracker.google.com/64450768
Bug: https://github.com/android-ndk/ndk/issues/507
Test: ran tests, plus manual readelf on the _test.o files
Change-Id: I3de6015921195304ea9c829ef31665cd34664066
strace 4.19 causes clang to emit a questionable warning:
external/strace/nlattr.c:254:35: error: format specifies type 'unsigned long' but the argument has type 'unsigned long long' [-Werror,-Wformat]
tprintf("htobe64(%" PRIu64 ")", be64toh(num));
~~~ ^~~~~~~~~~~~
bionic/libc/include/sys/endian.h💯20: note: expanded from macro 'be64toh'
#define be64toh(x) htobe64(x)
^~~~~~~~~~
bionic/libc/include/sys/endian.h:80:17: note: expanded from macro 'htobe64'
#define htobe64 __swap64
^
bionic/libc/include/sys/endian.h:48:18: note: expanded from macro '__swap64'
#define __swap64 __builtin_bswap64
^
What's happened here is:
* be64toh is __builtin_bswap64
* PRIu64 is "lu"
* __builtin_bswap64 is internally declared a "ULLiULLi"
All of which leads to the `unsigned long` != `unsigned long long` complaint.
It seems like __builtin_bswap64 should be ULiULi on 64-bit architectures,
where `long` rather than `long long` is the natural way to refer to 64-bit
types, as evidenced by the "lu" for PRIu64.
As long as clang behaves like this, though, we can work around it with a cast.
Also clean up the other casts in the file, be more consistent about whether
these function-like macros are defined with an argument, and remove an
incorrect comment.
Bug: http://b/65495954
Test: ran tests, built strace 4.19 without warnings
Change-Id: I8e06d4bf71e95d62f556eab8661033e04d487e0d
FORTIFY's *_chk functions mess with ASAN's library function
interceptors, which can apparently result in false-positives.
Since adding even more complexity to every run-time check condition in
FORTIFY doesn't seem like a great idea, and the majority of our builds
will still use FORTIFY anyway, turning FORTIFY off here seems
reasonable.
Bug: 63104159
Test: checkbuild on internal master + CtsBionicTestCases. No new
failures.
Change-Id: Id32e551e28ee70a9815ad140c3253b86f03de63f
This reverts commit 9af9120091 (a revert
of 079bff4fa5), now the versioner bug is
fixed.
Bug: http://b/64613623 # header bug
Bug: http://b/64802958 # versioner bug
Change-Id: I1cb9d7832d4b3aecdc57a9285e2291443e59d02d
This reverts commit 079bff4fa5.
Broke builds with SANITIZE_HOST=address with an asan failure in versioner.
Change-Id: I22b113fd5405589d1a25e5e137c450aaba1ade5f
GCC's FORTIFY required optimizations to be enabled in order to function
properly. Clang's FORTIFY doesn't have this limitation, so it seems
pointless to keep it disabled due to a GCC-specific limitation.
Bug: 12231437
Test: Checkbuild on bullhead internal master + CtsBionicTestCases. No
new failures.
Change-Id: I74aa35f9d3f3d2a6b11a7adfe72a787e3d7f7f36
We've never really used __restrict: only <string.h> and <stdio.h> (which
are still very similar to upstream BSD headers) consistently have these
annotations. Neither clang nor GCC warns for trivial cases, and there's
little obvious documentation benefit.
Bug: http://b/30833514
Test: builds
Change-Id: I3e4384281865475d0c55d764b546d8166419ee31
I plan on having one review per file for the enable_if->diagnose_if
FORTIFY migration. Having this in means that no one review is dependent
on another.
Bug: 12231437
Test: m.
Change-Id: Ic0b07d7f7f6782e371c8792eb1e40cdfa32d3e35
This patch cleans up our standard headers by moving most of the FORTIFY
cruft out in to its own sandbox. In order to include the *_chk and
*_real declarations, you can either enable FORTIFY, or `#define
__BIONIC_DECLARE_FORTIFY_HELPERS`.
Both sys/select.h and strings.h are explicitly ignored by this patch.
Both of these files have very small __BIONIC_FORTIFY blocks, and don't
define any actual FORTIFY'ed functions (just macros, and 3 *_chk
functions).
This patch also makes the versioner ignore the FORTIFY implementation
headers, since we're guaranteed to pick the FORTIFY'ed headers up when
looking at the regular headers. (...Not to mention that making the
FORTIFY'ed headers freestanding would be annoying to do and maintain for
~no benefit).
We bake the knowledge of where FORTIFY headers live directly into the
versioner. We could go with a more general approach (e.g. adding an -X
IGNORED_FILE flag that tells the versioner to ignore
$HEADER_PATH/$IGNORED_FILE), but we'd then have to repeat that for every
test, every manual invocation of the versioner, etc. for no benefit
that's obvious to me.
Bug: 12231437
Test: m checkbuild on bullhead internal master + CtsBionicTestCases. no
new errors.
Change-Id: Iffc0cc609009b33d989cdaddde0a809282131a5b
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
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
