We couldn't fix this for 32-bit because there's too much broken
code out there. (Pretty much everyone asks for real-time
scheduling for all their threads, and the kernel says "don't be
stupid".)
Change-Id: I43c5271e6b6bb91278b9a19eec08cbf05391e3c4
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
Previously, FORTIFY_SOURCE used single macros to define these standard
functions for use with clang. This can cause conflicts with other macros used
to call these functions, particularly when those macros expand the number of
arguments to the function. This change wraps our macro definitions, so that
expansion properly takes place for programmer arguments first.
Change-Id: I55929b1fd2a643b9d14a17631c4bcab3b0b712cf
Warnings are errors for all home-grown bionic code, and the arch-specific
code now counts as home-grown bionic code (it was mistakenly counted as
"not ours" before).
Change-Id: I9c6a881b0dc596bae7dfe112c5c189e073800a3a
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
If __get_tls has the right type, a lot of confusing casting can disappear.
It was probably a mistake that __get_tls was exposed as a function for mips
and x86 (but not arm), so let's (a) ensure that the __get_tls function
always matches the macro, (b) that we have the function for arm too, and
(c) that we don't have the function for any 64-bit architecture.
Change-Id: Ie9cb989b66e2006524ad7733eb6e1a65055463be
libc/tzcode/localtime.c: In function 'differ_by_repeat':
libc/tzcode/localtime.c:338:2: error: comparison is always false due to limited range of data type [-Werror=type-limits]
Change-Id: Ic84be6391a66e9d50ed98f41d865387c77a60ffa
Normally we don't have -Werror for upstream code, but for those warnings
that probably point to 32-bit assumptions about pointers, we want those
warnings to always be errors.
Change-Id: Ibece9caf09b2f7989ca600ef448d07868669a8fb
We shouldn't have been passing the bottom 32 bits of the address used
for pthread_join to the kernel.
Change-Id: I487e5002d60c27adba51173719213abbee0f183f
