The error handling was a mess, resulting in an infinite loop
(and a test timeout) if you actually took the /dev/urandom
fallback. I'm also unconvinced that the getrandom(2) path was correct
because of the various reasons why we might get a short count back
(http://man7.org/linux/man-pages/man2/getrandom.2.html). In this version,
the two paths look very similar except for the getrandom(2) failure case,
where it's now much clearer that we just give up so that we can boot
(http://b/33059407).
Bug: http://b/33059407
Bug: http://b/67015565
Test: ran tests on hikey and a ICS Galaxy Nexus
Change-Id: Ie715d59b46f7a70bae66943c316168838787b40d
ld-android.so exports exact same set of symbols
as linker. Since it is not supposed to be loaded
every symbol points to fail() method.
Test: make
Test: bionic-unit-tests --gtest_filter=dl*
Change-Id: I23bec365b302ce4ddf5f08832e665ae2b181cf8a
These are still needed for backwards compatibility with code built by old
versions of the NDK, but we don't need to pollute the headers with them.
Also lose the hand-written code for these. The compiler-generated code
is either the same or better, and no new code is calling these functions
anyway.
Bug: N/A
Test: ran tests
Change-Id: Ib01ad9805034433e0105aec882608cc8e6526f78
Add all the missing <netdb.h> functions.
Also fix getservbyport to handle a null protocol correctly.
Also fix getservbyname/getservbyport to not interfere with getservent.
Also fix endservent to reset getservent iteration.
Also reduce unnecessary differences from upstream NetBSD sethostent.c.
The servent implementation is still horrific, and we should
probably support protoent too so that debugging tools can use
getprotobyname/getprotobynumber.
Bug: N/A
Test: ran tests
Change-Id: I639108c46df0a768af297cf3bbce857cb1bef9d9
<machine/asm.h> was internal use only.
<machine/fenv.h> is quite large, but can live in <bits/...>.
<machine/regdef.h> is trivially replaced by saying $x instead of x in
our assembler.
<machine/setjmp.h> is trivially inlined into <setjmp.h>.
<sgidefs.h> is unused.
Bug: N/A
Test: builds
Change-Id: Id05dbab43a2f9537486efb8f27a5ef167b055815
This is the FreeBSD implementation, plus some tests. The FreeBSD
implementation includes the GNU extensions and seems to be what
iOS is using too, which should provide bug compatibility for app
developers.
The code unfortunately uses a lot of stack, and uses FreeBSD locale
implementation that we don't have, but it does seem better maintained
than the other BSDs.
Bug: http://b/29251134
Test: ran tests
Change-Id: Ie477b45e42a6df1319b25712098519d2b33adf67
I'm unable to find a bug, but we've had requests for this internally
once or twice (though I pointed those folks at the STL), and there's
code we build for the host or in our bootloaders that would use this,
and there's reasonable-looking FreeBSD implementation ready and waiting.
Bug: N/A
Test: ran tests
Change-Id: I6ddee4b71bea4c22ed015debd31d3eaac4fcdd35
For the libandroid_support NOTICE file, we need to combine all the files
in that directory, plus the specific files pulled from bionic.
Also cleaned up some of the Python style.
Bug: N/A
Test: used for libandroid_support
Change-Id: If433e3a0f0478f06d99a9b3556e99dde06a7e5e1
Some of this code is used in the NDK libandroid_support now, as a static
library, so just being HIDDEN in the ELF sense isn't sufficient.
Rename digittoint to __libm_digittoint so we don't trample anyone's toes.
Also remove imprecise_powl and imprecise_tgammal. It turns out (to my
surprise) that we don't even have ld128 implementations of powl and tgammal,
so even LP64 was just using the "fake_long_double.c" hack in effect. Since
that's the case, let's *actually* do that because then we're not polluting
with the internal names in addition to the aliases.
Bug: N/A
Test: readelf
Change-Id: I273cc8fdc7ce53f9b8dfd4ef7796e358fe901837
We've had <arpa/telnet.h> for years, despite being slightly more useless
than <arpa/ftp.h> and <arpa/tftp.h>. The inetutils package expects these
to be available.
Bug: http://b/63145226
Test: builds
Change-Id: I1e3c7421779e965b3342d681fefb8dc2561b604d
This change was forgotten when I uploaded tzlookup.xml for
review. I meant to check this with enh@. Apologies. This fixes
the the NOTICE file so others can upload.
Test: repo upload
Change-Id: I9e722952f9ae8c8d971b1c2d23d53079d85f4ae7
Test: Used bionic tests available under bionic/tests folder.
Tested for mips32r1/mips32r2/mips64r6 on emulators.
Change-Id: I589415ddc496df3f6067ae34cb33ca58b3a1f276
Signed-off-by: Prashant Patil <prashant.patil@imgtec.com>
Historically we had part of the linker licensed under BSD and
another part under Apache 2 license. This commit makes all the
linker code licensed under BSD license.
Test: m
Change-Id: I11b8163ae75966b5768d3fe992679de376106515
Provide stub for unused but needed symbol __find_icu_symbol
which is not included to libc_nomalloc.a.
Test: mm and boot
Change-Id: I57ca09c990556d1d401e2f4a75bc49b61b4cd85d
A kernel change is going in for 64bit arm to disable kuser_helper vector
pages for 32bit processes. This change adds a special elf note to
all arm32 binaries built with bionic. This note tells the kernel to
load the kuser_helper vector page for the process.
Bug: 33689037
Test: Manual - Phone boots, 32bit binaries have the notes, 64bit
binaries do not.
Change-Id: Ib8366e2a0810092b71381d57dee4bdaa56369a24
<sys/limits.h> shouldn't even exist, but leave it in for backwards
compatibility.
Everything that seems legit moves to <limits.h>, though it still seems
like a lot of that ought to come from the compiler instead (there's even
an angry rant in the clang header to that effect).
Unfortunately, we've long exposed [a copy and paste of] the contents
of <float.h> from <limits.h> and <sys/limits.h>. This patch preserves
that for backwards compatibility, but at least switches us over to
using the real <float.h> instead.
Bug: http://b/32776472
Test: builds
Change-Id: I2d5b3b5237b3a0442195e99bb967c076ce484f35
* Bionic benchmarks results at the bottom
* This is a squash of the following commits:
libc: ARM64: optimize memset.
This is an optimized memset for AArch64. Memset is split into 4 main
cases: small sets of up to 16 bytes, medium of 16..96 bytes which are
fully unrolled. Large memsets of more than 96 bytes align the
destination and use an unrolled loop processing 64 bytes per
iteration. Memsets of zero of more than 256 use the dc zva
instruction, and there are faster versions for the common ZVA sizes 64
or 128. STP of Q registers is used to reduce codesize without loss of
performance.
Change-Id: I0c5b5ec5ab8a1fd0f23eee8fbacada0be08e841f
libc: ARM64: improve performance in strlen
Change-Id: Ic20f93a0052a49bd76cd6795f51e8606ccfbf11c
libc: ARM64: Optimize memcpy.
This is an optimized memcpy for AArch64. Copies are split into 3 main
cases: small copies of up to 16 bytes, medium copies of 17..96 bytes
which are fully unrolled. Large copies of more than 96 bytes align
the destination and use an unrolled loop processing 64 bytes per
iteration. In order to share code with memmove, small and medium
copies read all data before writing, allowing any kind of overlap. On
a random copy test memcpy is 40.8% faster on A57 and 28.4% on A53.
Change-Id: Ibb9483e45bbc0e8ca3d5ce98a31c55dfd8a5ac28
libc: AArch64: Tune memcpy
* Further tuning for performance.
Change-Id: Id08eaab885f9743fa7575077924a947c1b88e4ff
libc: ARM64: optimize memmove for Cortex-A53
* Sadly does not work on Denver or Kryo, so can't go to generic
This is an optimized memmove for AArch64. All copies of up to 96
bytes and all backward copies are done by the new memcpy. The only
remaining case is large forward copies which are done in the same way
as the memcpy loop, but copying from the end rather than the start.
Tested on the Nextbit Robin with MSM8992 (Snapdragon 808):
Before
BM_string_memcmp/8 1000k 27 0.286 GiB/s
BM_string_memcmp/64 50M 20 3.053 GiB/s
BM_string_memcmp/512 20M 126 4.060 GiB/s
BM_string_memcmp/1024 10M 234 4.372 GiB/s
BM_string_memcmp/8Ki 1000k 1726 4.745 GiB/s
BM_string_memcmp/16Ki 500k 3711 4.415 GiB/s
BM_string_memcmp/32Ki 200k 8276 3.959 GiB/s
BM_string_memcmp/64Ki 100k 16351 4.008 GiB/s
BM_string_memcpy/8 1000k 13 0.612 GiB/s
BM_string_memcpy/64 1000k 8 7.187 GiB/s
BM_string_memcpy/512 50M 38 13.311 GiB/s
BM_string_memcpy/1024 20M 86 11.858 GiB/s
BM_string_memcpy/8Ki 5M 620 13.203 GiB/s
BM_string_memcpy/16Ki 1000k 1265 12.950 GiB/s
BM_string_memcpy/32Ki 500k 2977 11.004 GiB/s
BM_string_memcpy/64Ki 500k 8003 8.188 GiB/s
BM_string_memmove/8 1000k 11 0.684 GiB/s
BM_string_memmove/64 1000k 16 3.855 GiB/s
BM_string_memmove/512 50M 57 8.915 GiB/s
BM_string_memmove/1024 20M 117 8.720 GiB/s
BM_string_memmove/8Ki 2M 853 9.594 GiB/s
BM_string_memmove/16Ki 1000k 1731 9.462 GiB/s
BM_string_memmove/32Ki 500k 3566 9.189 GiB/s
BM_string_memmove/64Ki 500k 7708 8.501 GiB/s
BM_string_memset/8 1000k 16 0.487 GiB/s
BM_string_memset/64 1000k 16 3.995 GiB/s
BM_string_memset/512 50M 37 13.489 GiB/s
BM_string_memset/1024 50M 58 17.405 GiB/s
BM_string_memset/8Ki 5M 451 18.160 GiB/s
BM_string_memset/16Ki 2M 883 18.554 GiB/s
BM_string_memset/32Ki 1000k 2181 15.022 GiB/s
BM_string_memset/64Ki 500k 4563 14.362 GiB/s
BM_string_strlen/8 1000k 8 0.965 GiB/s
BM_string_strlen/64 1000k 16 3.855 GiB/s
BM_string_strlen/512 20M 92 5.540 GiB/s
BM_string_strlen/1024 10M 167 6.111 GiB/s
BM_string_strlen/8Ki 1000k 1237 6.620 GiB/s
BM_string_strlen/16Ki 1000k 2765 5.923 GiB/s
BM_string_strlen/32Ki 500k 6135 5.341 GiB/s
BM_string_strlen/64Ki 200k 13168 4.977 GiB/s
After
BM_string_memcmp/8 1000k 21 0.369 GiB/s
BM_string_memcmp/64 1000k 28 2.272 GiB/s
BM_string_memcmp/512 20M 128 3.983 GiB/s
BM_string_memcmp/1024 10M 234 4.375 GiB/s
BM_string_memcmp/8Ki 1000k 1732 4.728 GiB/s
BM_string_memcmp/16Ki 500k 3485 4.701 GiB/s
BM_string_memcmp/32Ki 500k 7031 4.660 GiB/s
BM_string_memcmp/64Ki 200k 14296 4.584 GiB/s
BM_string_memcpy/8 1000k 5 1.458 GiB/s
BM_string_memcpy/64 1000k 7 8.952 GiB/s
BM_string_memcpy/512 50M 36 13.907 GiB/s
BM_string_memcpy/1024 20M 80 12.750 GiB/s
BM_string_memcpy/8Ki 5M 572 14.307 GiB/s
BM_string_memcpy/16Ki 1000k 1165 14.053 GiB/s
BM_string_memcpy/32Ki 500k 3141 10.430 GiB/s
BM_string_memcpy/64Ki 500k 7008 9.351 GiB/s
BM_string_memmove/8 50M 7 1.074 GiB/s
BM_string_memmove/64 1000k 9 6.593 GiB/s
BM_string_memmove/512 50M 37 13.502 GiB/s
BM_string_memmove/1024 20M 80 12.656 GiB/s
BM_string_memmove/8Ki 5M 573 14.281 GiB/s
BM_string_memmove/16Ki 1000k 1168 14.018 GiB/s
BM_string_memmove/32Ki 1000k 2825 11.599 GiB/s
BM_string_memmove/64Ki 500k 6548 10.008 GiB/s
BM_string_memset/8 1000k 7 1.038 GiB/s
BM_string_memset/64 1000k 8 7.151 GiB/s
BM_string_memset/512 1000k 29 17.272 GiB/s
BM_string_memset/1024 50M 53 18.969 GiB/s
BM_string_memset/8Ki 5M 424 19.300 GiB/s
BM_string_memset/16Ki 2M 846 19.350 GiB/s
BM_string_memset/32Ki 1000k 2028 16.156 GiB/s
BM_string_memset/64Ki 500k 4514 14.517 GiB/s
BM_string_strlen/8 1000k 7 1.120 GiB/s
BM_string_strlen/64 1000k 16 3.918 GiB/s
BM_string_strlen/512 50M 64 7.894 GiB/s
BM_string_strlen/1024 20M 104 9.815 GiB/s
BM_string_strlen/8Ki 5M 664 12.337 GiB/s
BM_string_strlen/16Ki 1000k 1291 12.682 GiB/s
BM_string_strlen/32Ki 1000k 2940 11.143 GiB/s
BM_string_strlen/64Ki 500k 6440 10.175 GiB/s
Change-Id: I635bd2798a755256f748b2af19b1a56fb85a40c6
Regenerating the NOTICE file the other day left me scratching my head at
various "how do they differ?" cases, resolved by this patch.
Test: N/A
Change-Id: I4230bfa1d7ec842a4b9fb8c73dd3b39443d74054
Generate a single NOTICE file rather than one per library. All the
headers come from libc these days anyway.
Test: tools/update_notice.sh
Bug: None
Change-Id: I127da185fdabc2815042e19aea74c507ec108f46
Also updates the license files, since apparently they're out of date.
Test: repo upload --cbr .
Bug: None
Change-Id: Ic8d855a7ee5185c4933da699292868e02ef79531
Also clean up some near-miss copyright headers in libm, and remove
some cruft in <grp.h>/<pwd.h> that the script can't automatically
ignore since we stripped all the tabs in those files.
Change-Id: I10796c54dda1ceba87822ae0de26b5d71b54972b
I've also added insque(3) and remque(3) (from NetBSD because the OpenBSD
ones are currently broken for non-circular lists).
I've not added the three hash table functions that should be in this header
because they operate on a single global hash table and thus aren't likely
to be useful.
Bug: https://code.google.com/p/android/issues/detail?id=73719
Change-Id: I97397a7b921e2e860fd9c8032cafd9097380498a
Also fix a few formatting issues in copyright headers that were confusing
the script (though obviously it would be better if the script were smarter).
Change-Id: I7f561bef4f84fdcbd84f375ee226bd65db0e507b
