clock_gettime was returning EINVAL for the values
produced by pthread_getcpuclockid.
Bug: 10346183
Change-Id: Iabe643d7d46110bb311a0367aa0fc737f653208e
Our intptr_t and uintptr_t aren't "long". Add a compilation test so we remember
to fix this to cope with 32- and 64-bit later.
Bug: http://code.google.com/p/android/issues/detail?id=57218
Change-Id: I2f816d339edb4f7d57e4418b818fb4c602093f38
Get rid of a lot of the duplication in the various FORTIFY_SOURCE
tests. Instead, we build 4 separate static libraries, with
4 different compile time options, and link them into the final test
binary.
Change-Id: Idb0b7cccc8dd837adb037bf4ddfe8942ae138230
Kernel provides virtual DSO for stack unwinding/exception handlind info for
signal usage case. Stack unwinding routines use 'dl_iterate_phdr' function
for additional DWARF info gathering from DSOs. Patch enables virtual DSO
enumeration via dl_iterate_phdr function.
Signed-off-by: Sergey Melnikov <sergey.melnikov@intel.com>
Change-Id: Ic2882b28f40b456a088bc1e63c50cbfda7e4a102
In 829c089f83, we disabled all
FORTIFY_SOURCE support when compiling under clang. At the time,
we didn't have proper test cases, and couldn't easily create targeted
clang tests.
This change re-enables FORTIFY_SOURCE support under clang for a
limited set of functions, where we have explicit unittests available.
The functions are:
* memcpy
* memmove
* strcpy
* strncpy
* strcat
* strncat
* memset
* strlen (with modifications)
* strchr (with modifications)
* strrchr (with modifications)
It may be possible, in the future, to enable other functions. However,
I need to write unittests first.
For strlen, strchr, and strrchr, clang unconditionally calls the
fortified version of the relevant function. If it doesn't know the
size of the buffer it's dealing with, it passes in ((size_t) -1),
which is the largest possible size_t.
I added two new clang specific unittest files, primarily copied
from fortify?_test.cpp.
I've also rebuild the entire system with these changes, and didn't
observe any obvious problems.
Change-Id: If12a15089bb0ffe93824b485290d05b14355fcaa
- Implemented chk_memalign.
- Fixed a few bugs in leak_memalign.
- Implemented {leak,fill,check,qemu}_malloc_usable_size.
- Make malloc_usable_size update at run time.
- Add malloc_test.cpp as a small set of tests for the
malloc debug routines.
- Fix the qemu routines since it's been broken since it moved to C++.
- Add support for the %u format to the out_vformat in libc_logging.cpp.
This is used by the emulator code.
Tested using the bionic-unit-tests with setprop libc.debug.malloc
set to 1, 5, and 10.
I tested as much as possible on the emulator, but tracing doesn't appear
to be working properly.
Bug: 6143477
Merge change from internal master.
(cherry-picked from commit 3d594c2580)
Change-Id: I4ae00fffba82315a8c283f35893fd554460722fb
Add support for fortify source level 2 to strncpy.
This will enable detection of more areas where strncpy
is used inappropriately. For example, this would have detected
bug 8727221.
Move the fortify_source tests out of string_test.cpp, and
put it into fortify1_test.cpp.
Create a new fortify2_test.cpp file, which copies all
the tests in fortify1_test.cpp, and adds fortify_source level
2 specific tests.
Change-Id: Ica0fba531cc7d0609e4f23b8176739b13f7f7a83
- eventfd.cpp and eventfd.s will output to the same file when building libc.a
out/target/product/*/obj/STATIC_LIBRARIES/libc_intermediates/WHOLE/libc_common_objs/eventfd.o
- And then `eventfd` will undefined when statically linked to libc.
Also add a unit test.
Change-Id: Ib310ade3256712ca617a90539e8eb07459c98505
We only need one logging API, and I prefer the one that does no
allocation and is thus safe to use in any context.
Also use O_CLOEXEC when opening the /dev/log files.
Move everything logging-related into one header file.
Change-Id: Ic1e3ea8e9b910dc29df351bff6c0aa4db26fbb58
In the old code, the index was a file to itself, so it made sense to
read until you hit the end of the file. In the new code, the index is
followed by hundreds of KiB of data, so we need to just search the
index.
Bug: 8368791
Change-Id: Icf5f8b5516cf3a93679fa849c9f6cd1cb100e0f1
Normally, the C library implicitly caches your timezone by virtue
of the fact that the prehistoric API assumes a single timezone for
the entire process.
The unfortunate mktime_tz and localtime_tz extensions work around
this, but represent timezones as strings to their callers, so code
that makes heavy use of these needs a cache to be able to perform
acceptably until it can hopefully one day be rewritten to use
java.util.Calendar or icu4c.
Bug: 8270865
Change-Id: I92e3964e86dc33ceac925f819cc5e26ff4203f50
Some build servers are still out of date, so we're better off having
the known quanitity of the consistently out-of-date prebuilt host gcc.
Change-Id: Ib6308ae926ffa1ac5d95efbbf32052344c17a6b8
This reverts commit 6f94de3ca4
(Doesn't try to increase the number of TLS slots; that leads to
an inability to boot. Adds more tests.)
Change-Id: Ia7d25ba3995219ed6e686463dbba80c95cc831ca
This brings us up to date with FreeBSD HEAD, fixes various bugs, unifies
the set of functions we support on ARM, MIPS, and x86, fixes "long double",
adds ISO C99 support, and adds basic unit tests.
It turns out that our "long double" functions have always been broken
for non-normal numbers. This patch fixes that by not using the upstream
implementations and just forwarding to the regular "double" implementation
instead (since "long double" on Android is just "double" anyway, which is
what BSD doesn't support).
All the tests pass on ARM, MIPS, and x86, plus glibc on x86-64.
Bug: 3169850
Bug: 8012787
Bug: https://code.google.com/p/android/issues/detail?id=6697
Change-Id: If0c343030959c24bfc50d4d21c9530052c581837
Add a test to ensure that stack canaries are working
correctly. Since stack canaries aren't normally generated
on non-string functions, we have to enable stack-protector-all.
Add a test to ensure that an out of bounds strcpy generates
a runtime failure.
Change-Id: Id0d3e59fc4b9602da019e4d35c5c653e1a57fae4
The MIPS toolchain can't generate them because they're incompatible
with the MIPS ABI (which requires .dynsym match the GOT, while GNU-style
requires .dynsym to be sorted by hash code), so there's nothing to test.
Change-Id: I2220f452fe6fe595ec1312544cc741dd390a36a5
You could argue that this is hurting people smart enough to have manually
allocated a large-enough sigset_t, but those people are smart enough to
implement their own sigset functions too.
I wonder whether our least unpleasant way out of our self-inflicted 32-bit
cesspool is to have equivalents of _FILE_OFFSET_BITS such as _SIGSET_T_BITS,
so calling code could opt in? You'd have to be careful passing sigset_t
arguments between code compiled with different options.
Bug: 5828899
Change-Id: I0ae60ee8544835b069a2b20568f38ec142e0737b
Based on our open-source RE2 benchmarking code.
Includes benchmarks for a handful of <string.h> functions.
Change-Id: I30eb70d25dbf4ad5f2ca44976a8ce3b1ff7dad01
Also ensure that dlopen(3) errors always include the name of the library we
failed to open.
Also fix a bug where we'd fall back to searching LD_LIBRARY_PATH and the
built-in paths for names that include slashes.
Bug: http://code.google.com/p/android/issues/detail?id=38479
Change-Id: Ib2c009ed083344a7a012749d58f8679db2f26c78
Most of these tests were in system/extras, but I've added more to cover other
cases explicitly mentioned by POSIX.
Change-Id: I5e8d77e4179028d77306935cceadbb505515dcde
Based on a pair of patches from Intel:
https://android-review.googlesource.com/#/c/43909/https://android-review.googlesource.com/#/c/44903/
For x86, this patch supports _both_ the global that ARM/MIPS use
and the per-thread TLS entry (%gs:20) that GCC uses by default. This
lets us support binaries built with any x86 toolchain (right now,
the NDK is emitting x86 code that uses the global).
I've also extended the original tests to cover ARM/MIPS too, and
be a little more thorough for x86.
Change-Id: I02f279a80c6b626aecad449771dec91df235ad01
Also fix problem with multi-user IDs that the home directory was
returned as "/data" instead of "/" unlike all the other uids.
Change-Id: I914d22052e5a86552989f8969b85aadbc748c65d
Several previous changes conspired to make a mess of the thread list
in static binaries. This was most obvious when trying to call
pthread_key_delete(3) on the main thread.
Bug: http://code.google.com/p/android/issues/detail?id=36893
Change-Id: I2a2f553114d8fb40533c481252b410c10656da2e
