On Android, fcntl is always implemented by fcntl64(2). This means that
an LP32 binary can `fcntl(F_SETLK, struct flock)` (because fcntl64(2)
passes through to the 32-bit fcntl(2) to handle F_SETLK), and it can
also `fcntl(F_SETLK64, struct flock64)`. What it can't do before this
patch is set _FILE_OFFSET_BITS=64 and then `fcntl(F_SETLK, struct
flock)` where that `struct flock` is actually implicitly `struct
flock64`.
Move the kernel uapi structs out of the way, define them ourselves based
on __LP64__ and _FILE_OFFSET_BITS, and fix up the relevant F_ constants.
(Also add a .clang-format to turn off clang-format in libc/include/.)
Bug: N/A
Test: treehugger (and strace!)
Change-Id: Iccd6c83d9133e1efcf93a7b49a6ae0f1bbd3d58b
Historically we've made a few mistakes where they haven't matched the
right number. And most non-Googlers are much more familiar with the
numbers, so it seems to make sense to rely more on them. Especially in
header files, which we actually expect real people to have to read from
time to time.
Test: treehugger
Change-Id: I0d4a97454ee108de1d32f21df285315c5488d886
Remove some __INTRODUCED_IN(16)s, since we don't support anything lower
than 16, so that's a no-op. And add the missing doc comments to those
headers while we're there.
Test: treehugger
Change-Id: I0328c530675564f0f1124bd483da05ad06df3507
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 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
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
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
This patch adds clang-style FORTIFY to Bionic. For more information on
FORTIFY, please see https://goo.gl/8HS2dW . This implementation works
for versions of clang that don't support diagnose_if, so please see the
"without diagnose_if" sections. We plan to swap to a diagnose_if-based
FORTIFY later this year (since it doesn't really add any features; it
just simplifies the implementation a lot, and it gives us much prettier
diagnostics)
Bug: 32073964
Test: Builds on angler, bullhead, marlin, sailfish. Bionic CTS tests
pass on Angler and Bullhead.
Change-Id: I607aecbeee81529709b1eee7bef5b0836151eb2b
Bug: found when reproducing http://b/32331571
Test: "toybox fallocate -l 3m /data/local/tmp/new" on LP32
Change-Id: I4ec5835813b9556d824a12ad650bdf55698ea539
Future API levels aren't known (e.g. 25 could be a maintenance release
of N that doesn't contain any bionic updates), so use a placeholder
macro that we can find and replace with the actual API level before each
release.
Bug: http://b/28178111
Change-Id: I667fe53ea1ac49b64135170fc30d5dbe9df94e29
Glibc doesn't expose unlinkat in fcntl.h, this probably came about
because the man page for unlinkat mentions `#include <fcntl.h>` for the
AT_* constants that actually are defined there.
Bug: http://b/28067717
Change-Id: I769ca792a189bfea212b1d75096274acb0b7cfdb
This has been requested a few times over the years. This is basically
a very late rebase of https://android-review.googlesource.com/45470
which was abandoned years ago. One addition is that this version has
_FILE_OFFSET_BITS=64 support.
POSIX puts this in <unistd.h>. glibc also has it in <fcntl.h>.
Bug: http://b/13077650
Change-Id: I5862b1dc326e326c01ad92438ecc1578d19ba739
I still don't think we can make stdio's fseeko and ftello work, but we can
have everything else, and very few programs use fseeko/ftello (and they can
just refrain from using _FILE_OFFSET_BITS and be no worse off than they are
today).
Bug: 11865851
Change-Id: Ic3cb409aae6713f4b345de954bcc4241fcd969ec
<signal.h> shouldn't get you the contents of <errno.h>, and <fcntl.h>
shouldn't get you the contents of <unistd.h>.
Change-Id: I347499cd8671bfee98e6b8e875a97cab3a3655d3
POSIX says "The <fcntl.h> header shall define the symbolic constants for file
modes for use as values of mode_t as described in <sys/stat.h>".
Needed to build ToT strace.
Change-Id: Ia85a51ef6fd86a48084fe48ce24963000a937d37
__open_2() is used by the fortify implementation of open(2) in
fcntl.h, and as such needs an unmangled C name. For some reason
(inlining?), this doesn't cause problems at the default optimization
level, but does for -O0.
The rest of these didn't cause build failures, but they look suspect
and probably will, we just haven't caught them yet.
Bug: 17784968
Change-Id: I7391a7a8999ee204eaf6abd14a3d5373ea419d5b
Other changes to support the new headers:
- Remove the flock64 structure it is defined in the new headers.
- Update the syscalls to correspond with the headers.
Change-Id: I49a6b07e8b2bfffb67be71b07b58e4e6848fcc09
Fix and use __RENAME (and lose ___RENAME --- two underscores should be
enough for anybody). This was the point of this change, because I want
to use __RENAME to support the two basename variants and the two
strerror_r variants.
Lose a bunch of macros that weren't being used.
Lose three dead files from the DNS code.
Change-Id: I3ef645c566b16a52217bc2e68c7d54b37c7c9522
On LP64 systems F_GETLK64, F_SETLK64 and F_SETLKW64 definitions should
map onto the F_GETLK, F_SETLK and F_SETLKW definitions, respectively.
LP64 also doesn't have a struct flock64.
Change-Id: Ibdfed9645d9e946999acd6efa8b96ea6238ed5bf
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
This gives us:
* <dirent.h>
struct dirent64
readdir64, readdir64_r, alphasort64, scandir64
* <fcntl.h>
creat64, openat64, open64.
* <sys/stat.h>
struct stat64
fstat64, fstatat64, lstat64, stat64.
* <sys/statvfs.h>
struct statvfs64
statvfs64, fstatvfs64.
* <sys/vfs.h>
struct statfs64
statfs64, fstatfs64.
This also removes some of the incorrect #define hacks we've had in the
past (for stat64, for example, which we promised to clean up way back
in bug 8472078).
Bug: 11865851
Bug: 8472078
Change-Id: Ia46443521918519f2dfa64d4621027dfd13ac566
Even though code built with clang won't be fully fortified
and won't contain calls to our various helpers, binaries built
with GCC will.
Change-Id: I389b2f1e22a3e89b22aadedc46397bf704f9ca79
In 829c089f83, we disabled all
FORTIFY_SOURCE support when compiling under clang. At the time,
we didn't have proper test cases, and couldn't easily create targeted
clang tests.
This change re-enables FORTIFY_SOURCE support under clang for a
limited set of functions, where we have explicit unittests available.
The functions are:
* memcpy
* memmove
* strcpy
* strncpy
* strcat
* strncat
* memset
* strlen (with modifications)
* strchr (with modifications)
* strrchr (with modifications)
It may be possible, in the future, to enable other functions. However,
I need to write unittests first.
For strlen, strchr, and strrchr, clang unconditionally calls the
fortified version of the relevant function. If it doesn't know the
size of the buffer it's dealing with, it passes in ((size_t) -1),
which is the largest possible size_t.
I added two new clang specific unittest files, primarily copied
from fortify?_test.cpp.
I've also rebuild the entire system with these changes, and didn't
observe any obvious problems.
Change-Id: If12a15089bb0ffe93824b485290d05b14355fcaa
Define __errordecl and replace __attribute__((__error__("foo")))
with __errordecl. Make sure __errordecl is a no-op on clang, as it
generates a compile time warning.
Change-Id: Ifa1a2d3afd6881de9d479fc2adac6737871a2949
Also add a more intention-revealing guard so we don't have loads of
places checking whether our inlining macro is defined.
Change-Id: I168860cedcfc798b07a5145bc48a125700265e47
Clang and _FORTIFY_SOURCE are just plain incompatible with
each other. First of all, clang doesn't understand the
__attribute__((gnu_inline)) header. Second of all,
Clang doesn't have support for __builtin_va_arg_pack()
and __builtin_va_arg_pack_len() (see
http://clang.llvm.org/docs/UsersManual.html#c_unimpl_gcc)
Until we can resolve these issues, don't even try using
_FORTIFY_SOURCE under clang.
Change-Id: I81c2b8073bb3276fa9a4a6b93c427b641038356a
Add fortify_source support for openat(). This change requires that
an argument be supplied when using O_CREAT.
Fix unnecessary call to __open_2. If, at compile time, we know that
"flags" is constant and DOESN'T contain O_CREAT, the call to __open_2
is useless.
Change-Id: Ifcd29c4fb25e25656961d7552d672e161f0cfdbd
Add a FORTIFY_SOURCE check which requires that you pass a
"mode" argument when calling open(..., O_CREAT). If a mode isn't
passed, then the file is created with "undefined" permissions.
Change-Id: I4427be4f9ce170c69da01af5b00fb05b03613a28
