This change is intended to allow native-bridge to use independent
TLS memory for host and guest environments, while still sharing a
thread-local errno between the two.
Bug: http://b/78026329
Test: bionic unit tests
Change-Id: I838cd321e159add60760bc12a8aa7e9ddc960c33
Merged-In: I838cd321e159add60760bc12a8aa7e9ddc960c33
(cherry picked from commit a9c7c55462)
This breaks code that declares `errno` itself for whatever crazy reason:
b.c:22:12: error: conflicting types for '__errno'
extern int errno;
^
/usr/local/google/ndkports/toolchain/bin/../sysroot/usr/include/errno.h:47:20: note: expanded from macro 'errno'
#define errno (*__errno())
^
/usr/local/google/ndkports/toolchain/bin/../sysroot/usr/include/errno.h:44:15: note: previous declaration is here
volatile int* __errno(void) __attribute_const__;
^
Bug: N/A
Test: built various bits of GNU source
Change-Id: I27c03bf3bde419a001f98f1ea6c267c847f31271
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
