There's no reason to have multiple years in our own copyright headers,
and given the stupidity of our NOTICE file generation, it just creates
more junk.
Change-Id: I065a3811c2e2584e3b649a18ad9460286bc72b92
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
With a different memcpy, __memcpy_base_aligned ceased to exist.
Instead, point to the name defined by whatever includes memcpy_base.S
Change-Id: I242cf49cbada35337ba155d7f170e86a905ff55f
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
This makes unwind symbols 'protected',
which should prevent them from relocating
against libc++.so/libcutls.so.
This is temporary file and it is going
to be removed once libc.so stops exporting
them.
Bug: http://b/19958712
Change-Id: I96a765afe47e68d2e2ceb288870e63a25ca52081
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
The overflow's actually in the generic C implementation of memchr.
While I'm here, let's switch our generic memrchr to the OpenBSD version too.
Bug: https://code.google.com/p/android/issues/detail?id=147048
Change-Id: I296ae06a1ee196d2c77c95a22f11ee4d658962da
* 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
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
In https://android-review.googlesource.com/#/c/127908/5/libc/SYSCALLS.TXT@116
Elliott said:
for LP64 these will be hidden. for LP32 we were cowards and left
them all public for compatibility (though i don't think we ever
dremeled to see whether it was needed). we don't have an easy
way to recognize additions, though, so we can't prevent adding
new turds.
Add a mechanism to prevent the adding of new turds, and use that
mechanism on the fchmod/fchmodat system calls.
Bug: 19233951
Change-Id: I98f98345970b631a379f348df57858f9fc3d57c0
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
I also suspect that libc/arch-arm/bionic/memcmp.S is supposed to like in the
generic directory these days, but this change just removes dead code.
Change-Id: I9072488df6e9b7261d79b6014914a0e937cb387b
Directly save data into stack without properly adjustment
of stack point is dangous. For example, if a signal comes,
kernel will put sigframe into userspace's stack, which
will overwrite the saved data if sp is not adjusted properly.
Bug: 15195265
Change-Id: Iea0cadfd3b94d50cf40252ad52fe5950811b9192
Signed-off-by: Jiangli Yuan <a6808c@motorola.com>
Specifically, use the argument to sigsetjmp as a flag in the buffer
to indicate whether or not the signal mask is valid.
Bug: 16918359
Change-Id: I5bb1f1220f14c105c6bc57e0c28c1dc366d1438f
Note that this doesn't address the fact that we don't save/restore the
real-time signals. But it does let us pass the tests we currently fail.
Bug: 16918359
Change-Id: I063a6926164289a71026a412da7f5dd2ca9a74b3
When building with clang without this change, as errors out saying pldw
is an unsupported instruction (because it isn't part of the ARMv7 core
instruction set).
Let as know using pldw is fine.
Change-Id: Ie1f9c4b873e93ab2b3b374d2d46e476a4e581710
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
They'd drifted slightly which led to a compilation error in toybox,
which was assuming pid_t was defined. arm and arm64 were picking it
up via <endian.h> but x86 wasn't.
Change-Id: I58401e6c0066959dfc3b305b020876aaf7074bbf
- Clean up the labels (add .L to make them local).
- Change to using cfi directives.
- Fix unwinding of the __memcpy_chk fail path.
Bug: 18033671
Change-Id: I12845f10c7ce5e6699c15c558bda64c83f6a392a
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>
Remove the old arm directives.
Change the non-local labels to .L labels.
Add cfi directives to strcpy.S.
Change-Id: I9bafee1ffe5d85c92d07cfa8a85338cef9759562
This is needed to avoid multiple symbol definitions when linking with
libstdc++ or with compiler-rt.
Change-Id: I2f713bcff113222f0d2538e49691e715d8a8475d
* LP32 should use sa_restorer too. gdb expects this, and future (>= 3.15) x86
kernels will apparently stop supporting the case where SA_RESTORER isn't
set.
* gdb and libunwind care about the exact instruction sequences, so we need to
modify the code slightly in a few cases to match what they're looking for.
* gdb also cares about the exact function names (for some architectures),
so we need to use __restore and __restore_rt rather than __sigreturn and
__rt_sigreturn.
* It's possible that we don't have a VDSO; dl_iterate_phdr shouldn't assume
that getauxval(AT_SYSINFO_EHDR) will return a non-null pointer.
This fixes unwinding through a signal handler in gdb for all architectures.
It doesn't fix libunwind for arm and arm64. I'll keep investigating that...
Bug: 17436734
Change-Id: Ic1ea1184db6655c5d96180dc07bcc09628e647cb
The use of the .hidden directive to avoid going via the PLT for
__set_errno had the side-effect of actually making __set_errno
hidden (which is odd because assembler directives don't usually
affect symbols defined in a different file --- you can't even
create a weak reference to a symbol that's defined in a different
file).
This change switches the system call stubs over to a new always-hidden
__set_errno_internal and has a visible __set_errno on LP32 just for
binary compatibility with old NDK apps.
(cherry-pick of 7efad83d430f4d824f2aaa75edea5106f6ff8aae.)
Bug: 17423135
Change-Id: I6b6d7a05dda85f923d22e5ffd169a91e23499b7b
On most architectures the kernel subtracts a random offset to the stack
pointer in create_elf_tables by calling arch_align_stack before writing
the auxval table and so on. On all but x86 this doesn't cause a problem
because the random offset is less than a page, but on x86 it's up to two
pages. This means that our old technique of rounding the stack pointer
doesn't work. (Our old implementation of that technique was wrong too.)
It's also incorrect to assume that the main thread's stack base and size
are constant. Likewise to assume that the main thread has a guard page.
The main thread is not like other threads.
This patch switches to reading /proc/self/maps (and checking RLIMIT_STACK)
whenever we're asked.
Bug: 17111575
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
Change-Id: I1d4dbffe7bc7bda1d353c3a295dbf68d29f63158
In practice, with this implementation we never need to make a system call.
We get the main thread's tid (which is the same as our pid) back from
the set_tid_address system call we have to make during initialization.
A new pthread will have the same pid as its parent, and a fork child's
main (and only) thread will have a pid equal to its tid, which we get for
free from the kernel before clone returns.
The only time we'd actually have to make a getpid system call now is if
we take a signal during fork and the signal handler calls getpid. (That,
or we call getpid in the dynamic linker while it's still dealing with its
own relocations and hasn't even set up the main thread yet.)
Bug: 15387103
Change-Id: I6d4718ed0a5c912fc75b5f738c49a023dbed5189
The C library didn't export the 'index' symbol, but its C++ name-mangling
instead, which broke the ABI and prevented some applications from loading
properly.
The main reason was that the implementation under bionic/index.cpp relied
on the declaration to specify that the function has C linkage.
However, the declaration for index() was removed from both <string.h>
and <strings.h> in a recent patch, which made the compiler think it was
ok to compile the function with C++ linkage instead!
This patch does the following:
- Move index() definition to bionic/ndk_cruft.cpp and ensure it uses
C linkage.
Note that this removes index() from the 64-bit library entirely, this
is intentional and will break source compatibility. Simply replacing
an index() call with the equivalent strchr() should be enough to fix
this in third-party code.
- Remove bionic/index.cpp from the tree and build files.
- Remove x86 assembly implementation from arch-x86/ to avoid conflict
with the one in ndk_cruft.cpp
BUG=15606653
Change-Id: I816b589f69c8f8a6511f6be6195d20cf1c4e8123
These were both removed from POSIX 2004, and we don't define an
implementation for getw(3). Keep the definition of put(3) on LP32 for
binary compatibility.
Bug: 13935372
Change-Id: Iba384b45093ac6d2d7c2d81f7980cd7701dd6f56
vfork() was removed from POSIX 2008, so this replaces its implementation
with a call to fork().
Bug: 13935372
Change-Id: I6d99ac9e52a2efc5ee9bda1cab908774b830cedc
System calls can be pretty slow. This is mako, which has one of our
lowest latencies:
iterations ns/op
BM_unistd_getpid 10000000 209
BM_unistd_gettid 200000000 8
Bug: 15297299 (kernel panic from too many gettid calls)
Bug: 15315766 (excessive gettid overhead in liblogd)
Change-Id: I49656c0fc5b5d092390264a59e4f2c0d8a8b1aeb
The problem with the original patch was that using syscall(3) means that
errno can be set, but pthread_create(3) was abusing the TLS errno slot as
a pthread_mutex_t for the thread startup handshake.
There was also a mistake in the check for syscall failures --- it should
have checked against -1 instead of 0 (not just because that's the default
idiom, but also here because futex(2) can legitimately return values > 0).
This patch stops abusing the TLS errno slot and adds a pthread_mutex_t to
pthread_internal_t instead. (Note that for LP64 sizeof(pthread_mutex_t) >
sizeof(uintptr_t), so we could potentially clobber other TLS slots too.)
I've also rewritten the LP32 compatibility stubs to directly reuse the
code from the .h file.
This reverts commit 75c55ff84e.
Bug: 15195455
Change-Id: I6ffb13e5cf6a35d8f59f692d94192aae9ab4593d
This reverts commit ced906c849.
Causes issues on art / dalvik due to a broken return value
check and other undiagnosed issues.
bug: 15195455
Change-Id: I5d6bbb389ecefb0e33a5237421a9d56d32a9317c
Add optimized versions of bcopy and wmemmove for AArch64 based on the
memmove implementation
Change-Id: I82fbe8a7221ce224c567ffcfed7a94a53640fca8
Signed-off-by: Bernhard Rosenkraenzer <Bernhard.Rosenkranzer@linaro.org>
This reverts commit 8167dd7cb9.
For some reason I thought the bcopy change was bzero. The bcopy code doesn't pass our tests, so reverting until I can figure out what's wrong.
Change-Id: Id89fe959ea5105cd58dff6bba8d91a30cc4bcb07
Add optimized versions of bcopy and wmemmove for AArch64 based on the
memmove implementation
Change-Id: Ie43d0ff4f8ec4edba5b4fb5ccacd941f81ac6557
Signed-off-by: Bernhard Rosenkraenzer <Bernhard.Rosenkranzer@linaro.org>
Since __bionic_clone uses tail-call to invoke __bionic_clone_entry,
at runtime the unwinder will reach the stack of the clone() function,
which belongs to the parent thread, if the link register is not cleared.
BUG: 14270816
Change-Id: Ia3711c87f8b619debe73748c28b9fb8691ea698e
glibc doesn't have tkill or tgkill and says "use syscall(3) instead".
I've left tgkill since it's quite widely used, but there's no reason
to have tkill as well.
Bug: 11156955
Change-Id: Ifc0af750320086f829bc9914551c172b501f3b60
Also hide part of the system properties compatibility code, since
we needed to touch that to keep it building.
I'll remove __futex_syscall4 and futex in a later patch.
Bug: 11156955
Change-Id: Ibbf42414c5bb07fb9f1c4a169922844778e4eeae
This was accidentally added at a time when you couldn't add a constant
to <syscall.h> without generating an assembly stub! (You no longer need
to add the constants at all.)
Bug: 11156955
Change-Id: I053c17879138787976c744a5ecf7d30ee51dc48f
The library exists outside bionic. It is dynamically loaded, to replace selected
standard socket syscalls with versions that talk to netd.
Change connect() to use the library if available.
(cherry picked from commit 3a6b627a14df8111b03e452f2df4b5f4938e0e49)
Change-Id: Ib6198e19dbc306521a26fcecfdf6e8424d163fc9
Add following functions:
bcopy, memcpy, memmove, memset, bzero, memcmp, wmemcmp, strlen,
strcpy, strncpy, stpcpy, stpncpy.
Create new directories inside arch-x86 to specify architecture: atom,
silvermont and generic (non atom or silvermont architectures are treated like generic).
Due to introducing optimized versions of stpcpy and stpncpy,
c-implementations of these functions are moved from
common for architectures makefile to arm and mips specific makefiles.
Change-Id: I990f8061c3e9bca1f154119303da9e781c5d086e
Signed-off-by: Varvara Rainchik <varvara.rainchik@intel.com>
clone(2) is the public symbol.
Also switch a test from __bionic_clone to clone; testing public API
means the test now works on glibc too.
Change-Id: If59def26a00c3afadb8a6cf9442094c35a59ffde
This patch includes just enough to keep external/chromium_org building
until they switch 64-bit Android over to using the regular non-Android code.
Change-Id: Iecaf274efa46ae18a42d5e3439c5aa4f909177c1
Taking into account possibility that external symbol
could have been an OBJECT instead of function.
b/14090368
Change-Id: Iac173d2dd1309ed53024306578137c26b1dbbf15
The upstream intention was for this to be architecture-dependent, but it's a
lot clearer if we just have one copy.
Change-Id: I4e8310496145f9f411cd2e847c8cd023b1d758e9
