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
Many libc functions have an option to not follow symbolic
links. This is useful to avoid security sensitive code
from inadvertantly following attacker supplied symlinks
and taking inappropriate action on files it shouldn't.
For example, open() has O_NOFOLLOW, chown() has
lchown(), stat() has lstat(), etc.
There is no such equivalent function for chmod(), such as lchmod().
To address this, POSIX introduced fchmodat(AT_SYMLINK_NOFOLLOW),
which is intended to provide a way to perform a chmod operation
which doesn't follow symlinks.
Currently, the Linux kernel doesn't implement AT_SYMLINK_NOFOLLOW.
In GLIBC, attempting to use the AT_SYMLINK_NOFOLLOW flag causes
fchmodat to return ENOTSUP. Details are in "man fchmodat".
Bionic currently differs from GLIBC in that AT_SYMLINK_NOFOLLOW
is silently ignored and treated as if the flag wasn't present.
This patch provides a userspace implementation of
AT_SYMLINK_NOFOLLOW for bionic. Using open(O_PATH | O_NOFOLLOW),
we can provide a way to atomically change the permissions on
files without worrying about race conditions.
As part of this change, we add support for fchmod on O_PATH
file descriptors, because it's relatively straight forward
and could be useful in the future.
The basic idea behind this implementation comes from
https://sourceware.org/bugzilla/show_bug.cgi?id=14578 , specifically
comment #10.
Change-Id: I1eba0cdb2c509d9193ceecf28f13118188a3cfa7
Interestingly, this mostly involves cleaning up our implementation of
various <string.h> functions.
Change-Id: Ifaef49b5cb997134f7bc0cc31bdac844bdb9e089
Static libraries are painful. Details are in the comment. I'll try to
get prebuilts in to the tree so I can fix this on Monday. Until then,
this isn't actually a regression because we've not had coverage
available for this library until now anyway.
Bug: 17574078
Change-Id: I7505c8a94007203e15a6cf192caa06004849d7d9
We know we can safely statically link `libm`, since it doesn't have
any dependencies on the OS or the layout of a data type that has
changed between releases (like `pthread_t`).
We can safely statically link `libc_syscalls` because the user can
check for and handle `ENOSYS`.
Update `ndk_missing_symbols.py` to account for symbols that are in the
compatibility library.
Improve `symbols.py` to be able to pull symbols from a static library.
Change-Id: Ifb0ede1e8b4a8f0f33865d9fed72fb8b4d443fbc
This is correctness rather than performance, but found while investigating
performance.
Bug: 18593728
Change-Id: Idbdfed89d1931fcfae65db29d662108d4bbd9b65
change to behaviour the same as glibc for the check about buflen
Change-Id: I98265a8fe441df6fed2527686f89b087364ca53d
Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org>
Strictly speaking, this only implements the _l variants of the functions
we actually have. We're still missing nl_langinfo_l, for example, but we
don't have nl_langinfo either.
Change-Id: Ie711c7b04e7b9100932a13f5a5d5b28847eb4c12
Unless we completely redo how we build bionic (so that the object
files for libc.so get built separately from libc.a), we can't enable
ASAN here, as libc.a gets linked into static executables.
Change-Id: I2ce4f51248bd51c4213a555ff481b6faabbf53f8
All we're actually interested in is the unwinder. Since that's now a
separate library, just use that.
Change-Id: If86071a0d850da961336a58147b70369ace7bd12
Add the missing prototypes, fix the existing prototypes to use clockid_t
rather than int, fix clock_nanosleep's failure behavior, and add simple
tests.
Bug: 17644443
Bug: https://code.google.com/p/android/issues/detail?id=77372
Change-Id: I03fba369939403918abcabae9551a7123953d780
Signed-off-by: Haruki Hasegawa <h6a.h4i.0@gmail.com>
This means all our stdio implementation is now the OpenBSD implementation.
The only thing we lose is the STDIO_THREAD_LOCK calls but they were no-ops
anyway.
We should probably talk to upstream about this. Either fix the locking or,
preferably, encourage them to move away from this pooling (especially since
there's no eviction policy).
Bug: 17154680
Change-Id: Ie2523e444a7d0965b8d141d57e3e11f6432d5b9a
fpathconf(3) and pathconf(3) can share code. There's no such
header file as <pathconf.h>. glibc/POSIX and BSD disagree about where
the _POSIX_* definitions should go.
Change-Id: I4a67f1595c9f5fbb26700a131178eedebd6bf712
A lot of third-party code calls the private __get_thread symbol,
often as part of a backport of bionic's pthread_rwlock implementation.
Hopefully this will go away for LP64 (since you're guaranteed the
real implementation there), but there are still APIs that take a tid
and no way to convert between a pthread_t and a tid. pthread_gettid_np
is a public API for that. To aid the transition, make __get_thread
available again for LP32.
(cherry-pick of 27efc48814b8153c55cbcd0af5d9add824816e69.)
Bug: 14079438
Change-Id: I43fabc7f1918250d31d4665ffa4ca352d0dbeac1
Enable the -std=gnu++11 flag for libstdc++ static and
dynamic libs.
ScopeGuard uses DISABLE_ macros instead of '= delete';
Change-Id: I07e21b306f95fffd49345f7fa136cfdac61e0225
Clang is still disabled for x86 and x86_64 long double code,
for x86_64 special assembly instruction, and the linker module.
BUG: 17163651
BUG: 17302991
BUG: 17403674
Change-Id: I43c5f5f0ddc0c2a31918f00b57150dadd8f3f26b
This speeds up the debug malloc code by using the original unwinding code.
The only catch is that it has to link in the libc++ arm unwind code or
there will be crashes when attempting to unwind through libc++ compiled
code.
Bug: 16874447
(cherry picked from commit 3f7635f490)
Change-Id: If8a3821cdd95ed481bb496bf2daab449d13790f8
Create a method of disabling the debug allocation code paths so that
it's possible to use the libunwindbacktrace library without any
modifications.
Use this path to create and destroy the maps for the process. It's not
stricly necessary in the init code since the symbols are not modified
until after the initialize calls.
Also, remove the debug_XXX source files that doesn't need to be in libc.so.
Fix the maps reading code since it was completely broken for 64 bit.
Bug: 16408686
Change-Id: I6b02ef6ce26fdb7a59ad1029e7cbba9accceb704
Also clean up the implementation of all the pty functions, add tests,
and fix the stub implementations of ttyname(3) and ttyname_r(3).
Bug: https://code.google.com/p/android/issues/detail?id=58888
Change-Id: I0fb36438cd1abf8d4e87c29415f03db9ba13c3c2
