A continuation of commit 2825f10b7f.
Add O_PATH compatibility support for flistxattr(). This allows
a process to list out all the extended attributes associated with
O_PATH file descriptors.
Change-Id: Ie2285ac7ad2e4eac427ddba6c2d182d41b130f75
These are the problems fixed in this CL:
- The ndk_cruft.cpp file was not compiled for 64 bit.
- Some files where not compiled for libc_bionic.a due to a missing
patch-up-arch-specific-flags call.
- The libc_bionic_ndk.a patch up call was using bionic src, not
the bionic_ndk_src_files.
- Move mmap.cpp to the ndk src list where it was before because of
the above errors.
Bug: 21640784
Change-Id: I31e97bc8bf347c8e584cc17aa4b984a7d122b298
Support O_PATH file descriptors when handling fgetxattr and fsetxattr.
This avoids requiring file read access to pull extended attributes.
This is needed to support O_PATH file descriptors when calling
SELinux's fgetfilecon() call. In particular, this allows the querying
and setting of SELinux file context by using something like the following
code:
int dirfd = open("/path/to/dir", O_DIRECTORY);
int fd = openat(dirfd, "file", O_PATH | O_NOFOLLOW);
char *context;
fgetfilecon(fd, &context);
This change was motivated by a comment in
https://android-review.googlesource.com/#/c/152680/1/toys/posix/ls.c
Change-Id: Ic0cdf9f9dd0e35a63b44a4c4a08400020041eddf
All arch-arm and arch-arm64 .S files were compiled
by gcc with and without this patch. The output object files
were identical. When compiled with llvm and this patch,
the output files were also identical to gcc's output.
BUG: 18061004
Change-Id: I458914d512ddf5496e4eb3d288bf032cd526d32b
The visibility control in pthread_atfork.h is incorrect.
It breaks 64bit libc.so by hiding pthread_atfork.
This reverts commit 6df122f852.
Change-Id: I21e4b344d500c6f6de0ccb7420b916c4e233dd34
This doesn't affect code like Chrome that correctly ignores EINTR on
close, makes code that tries TEMP_FAILURE_RETRY work (where before it might
have closed a different fd and appeared to succeed, or had a bogus EBADF),
and makes "goto fail" code work (instead of mistakenly assuming that EINTR
means that the close failed).
Who loses? Anyone actively trying to detect that they caught a signal while
in close(2). I don't think those people exist, and I think they have better
alternatives available.
Bug: https://code.google.com/p/chromium/issues/detail?id=269623
Bug: http://b/20501816
Change-Id: I11e2f66532fe5d1b0082b2433212e24bdda8219b
NVIDIA binary blobs are assuming that __cache_clear, _Unwind_Backtrace,
and _Unwind_GetIP are all in some library that they link, but now we've
cleaned up this leakage, they're no longer getting it. Deliberately leak
the symbols from libc.so until we get new blobs.
Bug: http://b/20065774
Change-Id: I92ef07b2bce8d1ad719bf40dab41d745cd6904d4
This used to be handled by -fvisibility=hidden on libc_cxa, but that
was broken by the resolution of https://llvm.org/PR22419 (introduced
to Android in today's clang update).
Now we just use a version script that prevents these from being
re-exported from our shared libraries.
Change-Id: Ib290e1d0d7426e09ad17a91178162fff6dbdcfa9
This is initial implementations; does not yet handle
dlclose - undefined behavior, needs linker support to
handle it right.
Bug: 19800080
Bug: 16696563
Change-Id: I7a3e21ed7f7ec01e62ea1b7cb2ab253590ea0686
As glibc/netbsd don't protect access to thread struct members by a global
lock, we don't want to do it either. This change reduces the
responsibility of g_thread_list_lock to only protect g_thread_list.
Bug: 19636317
Change-Id: I897890710653dac165d8fa4452c7ecf74abdbf2b
The kernel system call faccessat() does not have any flags arguments,
so passing flags to the kernel is currently ignored.
Fix the kernel system call so that no flags argument is passed in.
Ensure that we don't support AT_SYMLINK_NOFOLLOW. This non-POSIX
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/access.html)
flag is a glibc extension, and has non-intuitive, error prone behavior.
For example, consider the following code:
symlink("foo.is.dangling", "foo");
if (faccessat(AT_FDCWD, "foo", R_OK, AT_SYMLINK_NOFOLLOW) == 0) {
int fd = openat(AT_FDCWD, "foo", O_RDONLY | O_NOFOLLOW);
}
The faccessat() call in glibc will return true, but an attempt to
open the dangling symlink will end up failing. GLIBC documents this
as returning the access mode of the symlink itself, which will
always return true for any symlink on Linux.
Some further discussions of this are at:
* http://lists.landley.net/pipermail/toybox-landley.net/2014-September/003617.html
* http://permalink.gmane.org/gmane.linux.lib.musl.general/6952
AT_SYMLINK_NOFOLLOW seems broken by design. I suspect this is why this
function was never added to POSIX. (note that "access" is pretty much
broken by design too, since it introduces a race condition between
check and action). We shouldn't support this until it's clearly
documented by POSIX or we can have it produce intuitive results.
Don't support AT_EACCESS for now. Implementing it is complicated, and
pretty much useless on Android, since we don't have setuid binaries.
See http://git.musl-libc.org/cgit/musl/commit/?id=0a05eace163cee9b08571d2ff9d90f5e82d9c228
for how an implementation might look.
Bug: 18867827
Change-Id: I25b86c5020f3152ffa3ac3047f6c4152908d0e04
We still have issues with clang coverage in static libraries, so we
need to make sure we follow suit with the rest of libc for now.
Bug: 17574078
Change-Id: I2ab58a84b1caa0d8d08415d240c35adec5b1e150
The replacement new failures present in newer versions are present
here as well, with the following new issues:
XPASS std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp
This is from the -NaN formatting fix in bionic. We previously had this
wrong, and the upstream test is also wrong. There's currently an XFAIL
for Android in this test because I haven't fixed the upstream test
yet. After that is done, I'll need to teach the test runner how to
XFAIL older Android versions...
FAIL std/localization/locale.categories/category.ctype/facet.ctype.special/facet.ctype.char.dtor/dtor.pass.cpp
dtor.pass.cpp:39: int main(): assertion "globalMemCounter.checkDeleteArrayCalledEq(1)" failed
Haven't investigated this one yet. http://b/19412688
Note that this also needs the libgcc link ordering to be fixed in the
build system, as we'll otherwise depend on libgcc symbols from libc
that may or may not have been there.
The build fix can't be submitted because the proper link order causes
the libgcc unwinder to be used instead of the EHABI one:
http://b/18471342
Bug: 18471532
Change-Id: Icf560485a9b8f5ebbe01e4458703e62ec94df5e1
Now passes all libc++ tests for these targets, with the exception of
the usual failing replacement new tests since libc uses new/delete for
things. I don't know if we can ever really fix these.
Bug: 18471532
Change-Id: Ibc0a15f26b0e4613249b5e15ecf3cf80e523467c
The .note.android.ident section is only used by GDB, which doesn't
care what section type the section is, but it would be convenient
for readelf -n to be able to find the section too.
The old way of getting the .note.android.ident section to be of type
SH_NOTE involved compiling from .c to .s using gcc, running sed to
change progbits to note, and then compiling from .s to .o using gcc.
Since crtbrand.c only contains a section containing data, a
crtbrand.S can be checked in that will compile on all platforms,
avoiding the need for sed.
Also add crtbrand.o to crtbegin_so.o so that libraries also get
the note, and to the crt workaround in arm libc.so.
Change-Id: Ica71942a6af4553b56978ceaa288b3f4c15ebfa2
* changes:
Use LOCAL_LDFLAGS_64 instead of enumerating 64-bit architectures
Fix typo in cpu variant makefile depenendency for arm64
Remove libc_static_common_src_files
Share LP32 makefile settings between arches
libc_static_common_src_files is never set after
c3f114037d, remove the remaining
references to it.
Change-Id: I66364a5c1b031ad69d608f6f44244049192944f6
Add <var>_32 to patch-up-arch-specific-flags, and move the LP32
cruft varaibles from the 32-bit arch specific makefiles into the
top level Android.mk.
Change-Id: Id3fcf6805d4af048c2524c94b1295416ebe7d057
