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
Also move isinf and isnan into libc like everyone else.
Also move fpclassify to libc like the BSDs (but unlike glibc). We need
this to be able to upgrade our float/double/long double parsing to gdtoa.
Also add some missing aliases. We now have all of:
isnan, __isnan, isnanf, __isnanf, isnanl, __isnanl,
isinf, __isinf, isinff, __isinff, isinfl, __isinfl,
__fpclassify, __fpclassifyd, __fpclassifyf, __fpclassifyl.
Bug: 13469877
Change-Id: I407ffbac06c765a6c5fffda8106c37d7db04f27d
the POSIX standard is that SIZE_MAX is defined
in stdint.h, not limits.h.
Change-Id: Iafd8ec71d1840541feaca4f53b2926b398293fac
Signed-off-by: Webb, Russell <russell.webb@intel.com>
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
Reviewed-by: Ross, Andrew J <andrew.j.ross@intel.com>
Reviewed-by: Boie, Andrew P <andrew.p.boie@intel.com>
Reviewed-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
Tested-by: Gumbel, Matthew K <matthew.k.gumbel@intel.com>
Add 32-bit bionic implementation for denver. Use denver version of memcpy/
memset. Use Cortex-A15 version of strlen/strcat/strcpy/strcmp.
Change-Id: I4c6b675f20cf41a29cadf70a11d1635d7df5b30a
Also add the corresponding constant, struct, and function declarations
to <sys/socket.h>, and perfunctory tests so we know that the symbols
actually exist.
Signed-off-by: Guillaume Ranquet <guillaumex.ranquet@intel.com>
Change-Id: Ib0d854239d3716be90ad70973c579aff4895a4f7
Why do we see so many bogus strict-aliasing warnings? Because we asked GCC to
cause trouble on arm and mips.
Change-Id: I25d7fd036b6afff7ccfa799abe0dc1579ead2847
Our <machine/asm.h> files were modified from upstream, to the extent
that no architecture was actually using the upstream ENTRY or END macros,
assuming that architecture even had such a macro upstream. This patch moves
everyone to the same macros, with just a few tweaks remaining in the
<machine/asm.h> files, which no one should now use directly.
I've removed most of the unused cruft from the <machine/asm.h> files, though
there's still rather a lot in the mips/mips64 ones.
Bug: 12229603
Change-Id: I2fff287dc571ac1087abe9070362fb9420d85d6d
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
1. Moved arch-specific setup to their own files:
- <arch>/<arch>.mk, arch-specific configs. Variables in those config
end with the arch name.
- removed the extra complexity introduced by function libc-add-cpu-variant-src,
which seems to be not very useful these days.
2. Separated out the crt object files generation rules and set up the
rules for both TARGET_ARCH and TARGET_2ND_ARCH.
3. Build all the libraries for both TARGET_ARCH and TARGET_2ND_ARCH,
with the arch-specific LOCAL_ variables.
Bug: 11654773
Change-Id: I9c2d85db0affa49199d182236d2210060a321421
Remove the linker's reliance on BSD cruft and use the glibc-style
ElfW macro. (Other code too, but the linker contains the majority
of the code that needs to work for Elf32 and Elf64.)
All platforms need dl_iterate_phdr_static, so it doesn't make sense
to have that part of the per-architecture configuration.
Bug: 12476126
Change-Id: I1d7f918f1303a392794a6cd8b3512ff56bd6e487
Most of <machine/_types.h> was either unused, wrong, or identical across
all 32-/64-bit architectures.
I'm not a huge fan of <sys/_types.h> either, but moving the bits we need
up into there is a step forward.
Bug: 12213562
Change-Id: Id13551c78966e324beee2dd90c5575e37d2a71e6
This is required to make the Nexus 10 graphics driver work on a system
compiled with gcc 4.9.
Change-Id: If3f3d488652a736d9ea3e583548d74fae3ffa902
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
The situation here is a bit confusing. On 64-bit, rlimit and rlimit64 are
the same, and so getrlimit/getrlimit64, setrlimit/setrlimit64,
and prlimit/prlimit64 are all the same. On 32-bit, rlimit and rlimit64 are
different. 32-bit architectures other than MIPS go one step further by having
an even more limited getrlimit system call, so arm and x86 need to use
ugetrlimit instead of getrlimit. Worse, the 32-bit architectures don't have
64-bit getrlimit- and setrlimit-equivalent system calls, and you have to use
prlimit64 instead. There's no 32-bit prlimit system call, so there's no
easy implementation of that --- what should we do if the result of prlimit64
won't fit in a struct rlimit? Since 32-bit survived without prlimit/prlimit64
for this long, I'm not going to bother implementing prlimit for 32-bit.
We need the rlimit64 functions to be able to build strace 4.8 out of the box.
Change-Id: I1903d913b23016a2fc3b9f452885ac730d71e001
This patch switches to using the uapi constants. It also adds the missing
setns system call, fixes sched_getcpu's error behavior, and fixes the
gensyscalls script now ARM is uapi-only too.
Change-Id: I8e16b1693d6d32cd9b8499e46b5d8b0a50bc4f1d
Also make the other architectures more similar to one another,
use NULL instead of 0 in calling code, and remove an unused #define.
Change-Id: I52b874afb6a351c802f201a0625e484df6d093bb
This is needed if we use Clang to compile Bionic, which won't include
__popcountsi2 anymore as Clang generates inline instructions. However
prebuilt binary blobs still depend on libc.so to resolve __popcountsi2.
Change-Id: I9001a3884c4be250c0ceebcd79922783fae1a0b7
This is a better solution than the old __warn_references because it's
a compile-time rather than link-time warning, it doesn't rely on something
that doesn't appear to be supported by gold (which is why you only used
to see these warnings on mips builds), and the errors refer to the exact
call site(s) rather than just telling you which object file contains a
reference to the bad function.
This is primarily so we can build bionic for aarch64; building libc.so
caused these warnings to fire (because link time is the wrong time) and
warnings are errors.
Change-Id: I5df9281b2a9d98b164a9b11807ea9472c6faa9e3
Since the ENTRY/END macros now have .cfi_startproc/.cfi_endproc, most of the
custom arm assembly has no unwind information. Adding the proper cfi directives
for these and removing the arm directives.
Update the gensyscalls.py script to add these cfi directives for the generated
assembly. Also fix the references to non-uapi headers to the proper uapi
header.
In addition, remove the kill.S, tkill.S, tgkill.S for arm since they are not
needed at all. The unwinder (libunwind) is able to properly unwind using the
normal abort.
After this change, I can unwind through the system calls again.
Bug: 11559337
Bug: 11825869
Bug: 11321283
Change-Id: I18b48089ef2d000a67913ce6febc6544bbe934a3
The kernel now maintains the pthread_internal_t::tid field for us,
and __clone was only used in one place so let's inline it so we don't
have to leave such a dangerous function lying around. Also rename
files to match their content and remove some useless #includes.
Change-Id: I24299fb4a940e394de75f864ee36fdabbd9438f9
Let the kernel keep pthread_internal_t::tid updated, including
across forks and for the main thread. This then lets us fix
pthread_join to only return after the thread has really exited.
Also fix the thread attributes of the main thread so we don't
unmap the main thread's stack (which is really owned by the
dynamic linker and contains things like environment variables),
which fixes crashes when joining with an exited main thread
and also fixes problems reported publicly with accessing environment
variables after the main thread exits (for which I've added a new
unit test).
In passing I also fixed a bug where if the clone(2) inside
pthread_create(3) fails, we'd unmap the child's stack and TLS (which
contains the mutex) and then try to unlock the mutex. Boom! It wasn't
until after I'd uploaded the fix for this that I came across a new
public bug reporting this exact failure.
Bug: 8206355
Bug: 11693195
Bug: https://code.google.com/p/android/issues/detail?id=57421
Bug: https://code.google.com/p/android/issues/detail?id=62392
Change-Id: I2af9cf6e8ae510a67256ad93cad891794ed0580b
We only need it for MAX_ERRNO, and it's time we had somewhere to put
the little assembler utility macros we've been putting off writing.
Change-Id: I9354d2e0dc47c689296a34b5b229fc9ba75f1a83
In practice, thanks to all the registers the stubs don't actually change,
but it's confusing to have an incorrect declaration.
I suspect that fcntl remains broken for aarch64; it happens to work for
x86_64 because the first vararg argument gets placed in the right register
anyway, but I have no reason to believe that's true for aarch64.
This patch adds a unit test, though, so we'll be able to tell when we get
as far as running the unit tests.
Change-Id: I58dd0054fe99d7d51d04c22781d8965dff1afbf3
I've left the exit_group syscall as _exit because otherwise we'd have to
convince the compiler that our _exit (which just calls __exit_group) is
actually "noreturn", and it seems like that would be less clean than just
cutting out the middleman.
We'll just have to trust ourselves not to add anything to SYSCALLS.TXT
that ought to be private but that only has a single leading underscore.
Hopefully we can manage that.
Change-Id: Iac47faea9f516186e1774381846c54cafabc4354
(aarch64 kernels only have the newer system calls.)
Also expose the new functionality that's exposed by glibc in our header files.
Change-Id: I45d2d168a03f88723d1f7fbf634701006a4843c5
Modern architectures only get the *at(2) system calls. For example,
aarch64 doesn't have open(2), and expects userspace to use openat(2)
instead.
Change-Id: I87b4ed79790cb8a80844f5544ac1a13fda26c7b5
Also clean up <signal.h> and revert the hacks that were necessary
for 64-bit in linker/debugger.cpp until now.
Change-Id: I3b0554ca8a49ee1c97cda086ce2c1954ebc11892
For some reason the new cortex-a15 memcpy code from ARM is really bad
for really large copies. This change forces us to go down the old path
for all copies.
All of my benchmarks show the new version is faster for large copies, but
something is going on that I don't understand.
Bug: 10838353
Change-Id: I01c16d4a2575e76f4c69862c6f78fd9024eb3fb8
I originally modified the krait mainloop prefetch from cacheline * 8 to * 2.
This causes a perf degradation for copies bigger than will fit in the cache.
Fixing this back to the original * 8. I tried other multiples, but * 8 is th
sweet spot on krait.
Bug: 11221806
Change-Id: I1f75fad6440f7417e664795a6e7b5616f6a29c45
Let's have both use rt_sigprocmask, like in glibc. The 64-bit ABIs
can share the same code as the 32-bit ABIs.
Also, let's test the return side of these calls, not just the
setting.
Bug: 11069919
Change-Id: I11da99f85b5b481870943c520d05ec929b15eddb
The x86_64 build was failing because clone.S had a call to __thread_entry which
was being added to a different intermediate .a on the way to making libc.so,
and the linker couldn't guarantee statically that such a relocation would be
possible.
ld: error: out/target/product/generic_x86_64/obj/STATIC_LIBRARIES/libc_common_intermediates/libc_common.a(clone.o): requires dynamic R_X86_64_PC32 reloc against '__thread_entry' which may overflow at runtime; recompile with -fPIC
This patch addresses that by ensuring that the caller and callee end up in the
same intermediate .a. While I'm here, I've tried to clean up some of the mess
that led to this situation too. In particular, this removes libc/private/ from
the default include path (except for the DNS code), and splits out the DNS
code into its own library (since it's a weird special case of upstream NetBSD
code that's diverged so heavily it's unlikely ever to get back in sync).
There's more cleanup of the DNS situation possible, but this is definitely a
step in the right direction, and it's more than enough to get x86_64 building
cleanly.
Change-Id: I00425a7245b7a2573df16cc38798187d0729e7c4
We shouldn't have been passing the bottom 32 bits of the address used
for pthread_join to the kernel.
Change-Id: I487e5002d60c27adba51173719213abbee0f183f
This is basically the other half of I5de76f6c46ac87779f207d568a86bb453e2414de
from Pavel Chupin <pavel.v.chupin@intel.com>, but taking the exact upstream
_types.h instead of the modified version. (I was confused when I suggested
otherwise.)
I've also cleaned up the internal_types.h situation; we weren't gaining
anything from these empty files, and there is no upstream internal_types.h
for x86_64.
Change-Id: I802a9a6a8df1c979e820659212c75a47c2ef392e
memcpy.a15.S/strcmp.a15.S files were submitted by ARM for use as the basis
for the memcpy/strcmp implementations in cortex-a15.
memset.S was moved in to the generic directory.
NOTE: memcpy.a9.S was submitted by Linaro to be the basis for the memcpy
for cortex-a9/cortex-a15 but has not been incorporated yet.
Bug: 10971279
Merge from internal master.
(cherry-picked from 48fc3e8b9f)
Change-Id: I8f9297578990d517f004e4e8840e2b2cbd5a47d8
The check for __ARM_FEATURE_DSP being defined is pointless since it
is always defined.
Bug: 10971279
Merge from internal master.
(cherry-picked from d2642fa70c)
Change-Id: If23ab3271f4da0c38cd531ffdc9a7e5eed6ec5dc
Much of the per-architecture duplication can be removed, so let's do so
before we add the 64-bit architectures.
Change-Id: Ieb796503c8e5353ea38c3bab768bb9a690c9a767
I accidentally did a signed comparison of the size_t values passed in
for three of the _chk functions. Changing them to unsigned compares.
Add three new tests to verify this failure is fixed.
Bug: 10691831
Merge from internal master.
(cherry-picked from 883ef2499c)
Change-Id: Id9a96b549435f5d9b61dc132cf1082e0e30889f5
The backtrace when a fortify check failed was not correct. This change
adds all of the necessary directives to get a correct backtrace.
Fix the strcmp directives and change all labels to local labels.
Testing:
- Verify that the runtime can decode the stack for __memcpy_chk, __memset_chk,
__strcpy_chk, __strcat_chk fortify failures.
- Verify that gdb can decode the stack properly when hitting a fortify check.
- Verify that the runtime can decode the stack for a seg fault for all of the
_chk functions and for memcpy/memset.
- Verify that gdb can decode the stack for a seg fault for all of the _chk
functions and for memcpy/memset.
- Verify that the runtime can decode the stack for a seg fault for strcmp.
- Verify that gdb can decode the stack for a seg fault in strcmp.
Bug: 10342460
Bug: 10345269
Merge from internal master.
(cherry-picked from 05332f2ce7)
Change-Id: Ibc919b117cfe72b9ae97e35bd48185477177c5ca
The libcorkscrew stack unwinder does not understand cfi directives,
so add .save directives so that it can function properly.
Also add the directives in to strcmp.S and fix a missing set of
directives in cortex-a9/memcpy_base.S.
Bug: 10345269
Merge from internal master.
(cherry-picked from 5f7ccea3ff)
Change-Id: If48a216203216a643807f5d61906015984987189
I accidentally did a signed comparison of the size_t values passed in
for three of the _chk functions. Changing them to unsigned compares.
Add three new tests to verify this failure is fixed.
Bug: 10691831
Change-Id: Ia831071f7dffd5972a748d888dd506c7cc7ddba3
The backtrace when a fortify check failed was not correct. This change
adds all of the necessary directives to get a correct backtrace.
Fix the strcmp directives and change all labels to local labels.
Testing:
- Verify that the runtime can decode the stack for __memcpy_chk, __memset_chk,
__strcpy_chk, __strcat_chk fortify failures.
- Verify that gdb can decode the stack properly when hitting a fortify check.
- Verify that the runtime can decode the stack for a seg fault for all of the
_chk functions and for memcpy/memset.
- Verify that gdb can decode the stack for a seg fault for all of the _chk
functions and for memcpy/memset.
- Verify that the runtime can decode the stack for a seg fault for strcmp.
- Verify that gdb can decode the stack for a seg fault in strcmp.
Bug: 10342460
Bug: 10345269
Change-Id: I1dedadfee207dce4a285e17a21e8952bbc63786a
The libcorkscrew stack unwinder does not understand cfi directives,
so add .save directives so that it can function properly.
Also add the directives in to strcmp.S and fix a missing set of
directives in cortex-a9/memcpy_base.S.
Bug: 10345269
Change-Id: I043f493e0bb6c45bd3f4906fbe1d9f628815b015
This change pulls the memcpy code out into a new file so that the
__strcpy_chk and __strcat_chk can use it with an include.
The new versions of the two chk functions uses assembly versions
of strlen and memcpy to implement this check. This allows near
parity with the assembly versions of strcpy/strcat. It also means that
as memcpy implementations get faster, so do the chk functions.
Other included changes:
- Change all of the assembly labels to local labels. The other labels
confuse gdb and mess up backtracing.
- Add .cfi_startproc and .cfi_endproc directives so that gdb is not
confused when falling through from one function to another.
- Change all functions to use cfi directives since they are more powerful.
- Move the memcpy_chk fail code outside of the memcpy function definition
so that backtraces work properly.
- Preserve lr before the calls to __fortify_chk_fail so that the backtrace
actually works.
Testing:
- Ran the bionic unit tests. Verified all error messages in logs are set
correctly.
- Ran libc_test, replacing strcpy with __strcpy_chk and replacing
strcat with __strcat_chk.
- Ran the debugger on nexus10, nexus4, and old nexus7. Verified that the
backtrace is correct for all fortify check failures. Also verify that
when falling through from __memcpy_chk to memcpy that the backtrace is
still correct. Also verified the same for __memset_chk and bzero.
Verified the two different paths in the cortex-a9 memset routine that
save variables to the stack still show the backtrace properly.
Bug: 9293744
(cherry-picked from 2be91915dc)
Change-Id: Ia407b74d3287d0b6af0139a90b6eb3bfaebf2155
This change creates assembler versions of __memcpy_chk/__memset_chk
that is implemented in the memcpy/memset assembler code. This change
avoids an extra call to memcpy/memset, instead allowing a simple fall
through to occur from the chk code into the body of the real
implementation.
Testing:
- Ran the libc_test on __memcpy_chk/__memset_chk on all nexus devices.
- Wrote a small test executable that has three calls to __memcpy_chk and
three calls to __memset_chk. First call dest_len is length + 1. Second
call dest_len is length. Third call dest_len is length - 1.
Verified that the first two calls pass, and the third fails. Examined
the logcat output on all nexus devices to verify that the fortify
error message was sent properly.
- I benchmarked the new __memcpy_chk and __memset_chk on all systems. For
__memcpy_chk and large copies, the savings is relatively small (about 1%).
For small copies, the savings is large on cortex-a15/krait devices
(between 5% to 30%).
For cortex-a9 and small copies, the speed up is present, but relatively
small (about 3% to 5%).
For __memset_chk and large copies, the savings is also small (about 1%).
However, all processors show larger speed-ups on small copies (about 30% to
100%).
Bug: 9293744
Merge from internal master.
(cherry-picked from 7c860db074)
Change-Id: I916ad305e4001269460ca6ebd38aaa0be8ac7f52
This change pulls the memcpy code out into a new file so that the
__strcpy_chk and __strcat_chk can use it with an include.
The new versions of the two chk functions uses assembly versions
of strlen and memcpy to implement this check. This allows near
parity with the assembly versions of strcpy/strcat. It also means that
as memcpy implementations get faster, so do the chk functions.
Other included changes:
- Change all of the assembly labels to local labels. The other labels
confuse gdb and mess up backtracing.
- Add .cfi_startproc and .cfi_endproc directives so that gdb is not
confused when falling through from one function to another.
- Change all functions to use cfi directives since they are more powerful.
- Move the memcpy_chk fail code outside of the memcpy function definition
so that backtraces work properly.
- Preserve lr before the calls to __fortify_chk_fail so that the backtrace
actually works.
Testing:
- Ran the bionic unit tests. Verified all error messages in logs are set
correctly.
- Ran libc_test, replacing strcpy with __strcpy_chk and replacing
strcat with __strcat_chk.
- Ran the debugger on nexus10, nexus4, and old nexus7. Verified that the
backtrace is correct for all fortify check failures. Also verify that
when falling through from __memcpy_chk to memcpy that the backtrace is
still correct. Also verified the same for __memset_chk and bzero.
Verified the two different paths in the cortex-a9 memset routine that
save variables to the stack still show the backtrace properly.
Bug: 9293744
Change-Id: Id5aec8c3cb14101d91bd125eaf3770c9c8aa3f57
(cherry picked from commit 2be91915dc)
Create one version of strcat/strcpy/strlen for cortex-a15/krait and another
version for cortex-a9.
Tested with the libc_test strcat/strcpy/strlen tests.
Including new tests that verify that the src for strcat/strcpy do not
overread across page boundaries.
NOTE: The handling of unaligned strcpy (same code in strcat) could probably
be optimized further such that the src is read 64 bits at a time instead of
the partial reads occurring now.
strlen improves slightly since it was recently optimized.
Performance improvements for strcpy and strcat (using an empty dest string):
cortex-a9
- Small copies vary from about 5% to 20% as the size gets above 10 bytes.
- Copies >= 1024, about a 60% improvement.
- Unaligned copies, from about 40% improvement.
cortex-a15
- Most small copies exhibit a 100% improvement, a few copies only
improve by 20%.
- Copies >= 1024, about 150% improvement.
- Unaligned copies, about 100% improvement.
krait
- Most small copies vary widely, but on average 20% improvement, then
the performance gets better, hitting about a 100% improvement when
copies 64 bytes of data.
- Copies >= 1024, about 100% improvement.
- When coping MBs of data, about 50% improvement.
- Unaligned copies, about 90% improvement.
As strcat destination strings get larger in size:
cortex-a9
- about 40% improvement for small dst strings (>= 32).
- about 250% improvement for dst strings >= 1024.
cortex-a15
- about 200% improvement for small dst strings (>=32).
- about 250% improvement for dst strings >= 1024.
krait
- about 25% improvement for small dst strings (>=32).
- about 100% improvement for dst strings >=1024.
Merge from internal master.
(cherry-picked from d119b7b6f4)
Change-Id: I296463b251ef9fab004ee4dded2793feca5b547a
This change creates assembler versions of __memcpy_chk/__memset_chk
that is implemented in the memcpy/memset assembler code. This change
avoids an extra call to memcpy/memset, instead allowing a simple fall
through to occur from the chk code into the body of the real
implementation.
Testing:
- Ran the libc_test on __memcpy_chk/__memset_chk on all nexus devices.
- Wrote a small test executable that has three calls to __memcpy_chk and
three calls to __memset_chk. First call dest_len is length + 1. Second
call dest_len is length. Third call dest_len is length - 1.
Verified that the first two calls pass, and the third fails. Examined
the logcat output on all nexus devices to verify that the fortify
error message was sent properly.
- I benchmarked the new __memcpy_chk and __memset_chk on all systems. For
__memcpy_chk and large copies, the savings is relatively small (about 1%).
For small copies, the savings is large on cortex-a15/krait devices
(between 5% to 30%).
For cortex-a9 and small copies, the speed up is present, but relatively
small (about 3% to 5%).
For __memset_chk and large copies, the savings is also small (about 1%).
However, all processors show larger speed-ups on small copies (about 30% to
100%).
Bug: 9293744
Change-Id: I8926d59fe2673e36e8a27629e02a7b7059ebbc98
Create one version of strcat/strcpy/strlen for cortex-a15/krait and another
version for cortex-a9.
Tested with the libc_test strcat/strcpy/strlen tests.
Including new tests that verify that the src for strcat/strcpy do not
overread across page boundaries.
NOTE: The handling of unaligned strcpy (same code in strcat) could probably
be optimized further such that the src is read 64 bits at a time instead of
the partial reads occurring now.
strlen improves slightly since it was recently optimized.
Performance improvements for strcpy and strcat (using an empty dest string):
cortex-a9
- Small copies vary from about 5% to 20% as the size gets above 10 bytes.
- Copies >= 1024, about a 60% improvement.
- Unaligned copies, from about 40% improvement.
cortex-a15
- Most small copies exhibit a 100% improvement, a few copies only
improve by 20%.
- Copies >= 1024, about 150% improvement.
- Unaligned copies, about 100% improvement.
krait
- Most small copies vary widely, but on average 20% improvement, then
the performance gets better, hitting about a 100% improvement when
copies 64 bytes of data.
- Copies >= 1024, about 100% improvement.
- When coping MBs of data, about 50% improvement.
- Unaligned copies, about 90% improvement.
As strcat destination strings get larger in size:
cortex-a9
- about 40% improvement for small dst strings (>= 32).
- about 250% improvement for dst strings >= 1024.
cortex-a15
- about 200% improvement for small dst strings (>=32).
- about 250% improvement for dst strings >= 1024.
krait
- about 25% improvement for small dst strings (>=32).
- about 100% improvement for dst strings >=1024.
Change-Id: Ifd091ebdbce70fe35a7c5d8f71d5914255f3af35
This is needed when passing -mcpu=cortex-a9 or higher on a modern
toolchain for prebuilt library compatibility
Change-Id: I73eb2393377914ae26216a8c2828ad973d1c1225
Tested using a static version of the strlen libc_test program
on a nexus7 that uses the generic code.
Merge from internal master.
(cherry-picked from d8d10a8994)
Change-Id: I88f7dc01dc5b5c3ac2d5580d92153bc1bc36c564
This optimized version is primarily targeted at cortex-a15.
Tested on all nexus devices using the system/extras/libc_test strlen test.
Tested alignments from 1 to 32 that are powers of 2.
Tested that strlen does not cross page boundaries at all alignments.
Speed improvements listed below:
cortex-a15
- Sizes >= 32 bytes, ~75% improvement.
- Sizes >= 1024 bytes, ~250% improvement.
cortex-a9
- Sizes >= 32 bytes, ~75% improvement.
- Sizes >= 1024 bytes, ~85% improvement.
krait
- Sizes >= 32 bytes, ~95% improvement.
- Sizes >= 1024 bytes, ~160% improvement.
Merge from internal master.
(cherry-picked from 2fc0717977)
Change-Id: I1ceceb4e745fd68e9d946f96d1d42e0cdaff6ccf
We cleaned up the auto-generated ones a while back to not touch
the stack unnecessarily if they have <= 4 arguments. This patch
cleans up some hand-crafted ones.
Also improve comments in clone.S.
Change-Id: I8850bf98f2b26829385315304472a760e6880ed8
Tested using a static version of the strlen libc_test program
on a nexus7 that uses the generic code.
Change-Id: If04d15dcb6c0b18f27f2fefadca5510ed49016c5
