code review 106380043: cmd/go, cmd/ld, runtime, os/user: TLS emultion for android

cmd/go, cmd/ld, runtime, os/user: TLS emulation for android

Based on cl/69170045 by Elias Naur.

There are currently several schemes for acquiring a TLS
slot to save the g register. None of them appear to work
for android. The closest are linux and darwin.

Linux uses a linker TLS relocation. This is not supported
by the android linker.

Darwin uses a fixed offset, and calls pthread_key_create
until it gets the slot it wants. As the runtime loads
late in the android process lifecycle, after an
arbitrary number of other libraries, we cannot rely on
any particular slot being available.

So we call pthread_key_create, take the first slot we are
given, and put it in runtime.tlsg, which we turn into a
regular variable in cmd/ld.

Makes android/arm cgo binaries work.

[crawshaw, 2014-07-02 02:59:38]

Hello elias.naur@gmail.com, minux@golang.org (cc:
golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go

[minux, 2014-07-02 04:21:15]

https://codereview.appspot.com/106380043/diff/40001/src/cmd/go/build.go
File src/cmd/go/build.go (right):

https://codereview.appspot.com/106380043/diff/40001/src/cmd/go/build.go#newco...
src/cmd/go/build.go:1745: compiler = append(compiler, "-llog")
put -llog as a #cgo LDFLAGS in runtime/cgo/cgo.go so that
we don't need to modify cmd/go for this.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/os/user/lookup_st...
File src/pkg/os/user/lookup_stubs.go (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/os/user/lookup_st...
src/pkg/os/user/lookup_stubs.go:5: // +build !cgo,!windows,!plan9 android
What's your plan for os/user on android?

do you intent to hardcode a table of uid/username pairs for android?

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_arm.s
File src/pkg/runtime/asm_arm.s (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_arm.s...
src/pkg/runtime/asm_arm.s:45: MOVW.NE $runtime·tlsg(SB), R2 	// arg 2: tlsg
.NE is unnecessary here.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_arm.s...
src/pkg/runtime/asm_arm.s:46: MRC     15, 0, R3, C13, C0, 3 	// arg 3: TLS base
pointer
because this instruction will be rewritten by the liblink if
GOARM < 7 to a BL runtime.read_tls_fallback(SB) instruction,
you have to use R0 for the register here.

otherwise you will break build for linux/arm with GOARM < 7.

also note, if you change the argument order, please also keep
the x_cgo_init function in pkg/runtime/cgo/gcc_{free,net}bsd_arm.c
up-to-date.

I will add a explicit check to liblink/obj5.c to diagnose
this case. (CL 107430044)

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
File src/pkg/runtime/asm_tls_android_arm.s (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
src/pkg/runtime/asm_tls_android_arm.s:5: #include "zasm_GOOS_GOARCH.h"
isn't asm_tls_android_arm.s too long?
I think tls_android_asm.s is perfectly fine.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
src/pkg/runtime/asm_tls_android_arm.s:17: MOVW	g, 0(R0)
MOVW g, R11<<0(R0)
instead of ADD and MOVW.
same below.

(yeah, the plan 9 arm assembler syntax is weird.
i hope the new assembler would recognize "R11(R0)")

should my nacl/arm changes go in first, you will
need to conditionally use the two-instruction sequence
just for nacl/arm.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
File src/pkg/runtime/asm_tls_arm.s (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
src/pkg/runtime/asm_tls_arm.s:12: // m(R9). One reason is that external code
might trigger
there is no m(R9) anymore. sync your client with the
tip please. the comment has already been updated.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
src/pkg/runtime/asm_tls_arm.s:23: //       runtime.mcall assumes this function
only clobbers R0 and R11.
this comment is fairly important, so I strongly suggest we merge
this file and the other android specific one.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
src/pkg/runtime/asm_tls_arm.s:29: MOVW	$runtime·tlsg(SB), R11
the difference between this file and the other is small enough so
i think using #ifdef GOOS_android is more appropriate.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_a...
File src/pkg/runtime/cgo/gcc_android_arm.c (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_a...
src/pkg/runtime/cgo/gcc_android_arm.c:13: // inittls finds the first available
pthread slot and uses it as
s/pthread slot/thread-local storage slot/

see pkg/runtime/cgo/gcc_darwin_386.c for an example of
this comment.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_a...
src/pkg/runtime/cgo/gcc_android_arm.c:28: for (i=0; i<50; i++) {
probably 50 is too small? darwin/386 tries 128 slots.

however, too big a number and we might get SIGSEGV/SIGBUS.

i wonder if we should just use pthread_getspecific in
load_g and save_g?

Either way we need to make a few assumptions.
1. (your current way) we can read at least N words of TLS without problem and
tls slots used by other part of the application is less than N.
2. (use pthread_getspecific always) it doesn't use much stack space so it can be
called from goroutine stack.

i think 2 is better than 1. what do you think?
of course, in load_g and save_g we need to save all the caller-save
registers, but it's not that bad. (we need to save r0-r3, r9, r12, r14)

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_a...
src/pkg/runtime/cgo/gcc_android_arm.c:41: void (*x_cgo_inittls)(void **tlsg,
void **tlsbase) = inittls;
i think you can remove the extern declaration here.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_l...
File src/pkg/runtime/cgo/gcc_linux_arm.c (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_l...
src/pkg/runtime/cgo/gcc_linux_arm.c:39: fprintf(stderr, "runtime/cgo:
pthread_create failed: %s\n", strerror(err));
should this message also be sent to __android_log_print?

[dfc, 2014-07-02 04:33:05]

https://codereview.appspot.com/106380043/diff/40001/src/cmd/go/build.go
File src/cmd/go/build.go (right):

https://codereview.appspot.com/106380043/diff/40001/src/cmd/go/build.go#newco...
src/cmd/go/build.go:1745: compiler = append(compiler, "-llog")
On 2014/07/02 04:21:14, minux wrote:
> put -llog as a #cgo LDFLAGS in runtime/cgo/cgo.go so that
> we don't need to modify cmd/go for this.

yup, good idea

https://codereview.appspot.com/106380043/diff/40001/src/cmd/ld/elf.c
File src/cmd/ld/elf.c (right):

https://codereview.appspot.com/106380043/diff/40001/src/cmd/ld/elf.c#newcode779
src/cmd/ld/elf.c:779: if(strcmp(goos, "android") != 0)
can you use (HEADTYPE == Handroid) here ?

https://codereview.appspot.com/106380043/diff/40001/src/cmd/ld/pobj.c
File src/cmd/ld/pobj.c (right):

https://codereview.appspot.com/106380043/diff/40001/src/cmd/ld/pobj.c#newcode145
src/cmd/ld/pobj.c:145: if(strcmp(goos, "android") == 0)
if(HEADTYPE == Handroid) maybe

needs a comment

// force external linking for android

possibly this should be handed by the go tool instead as it controls -linkmode

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_arm.s
File src/pkg/runtime/asm_arm.s (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_arm.s...
src/pkg/runtime/asm_arm.s:43: MOVW	g, R0 			// arg 0: G
if you're going to inline setg_gcc, please retain the comment.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
File src/pkg/runtime/asm_tls_arm.s (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
src/pkg/runtime/asm_tls_arm.s:29: MOVW	$runtime·tlsg(SB), R11
On 2014/07/02 04:21:15, minux wrote:
> the difference between this file and the other is small enough so
> i think using #ifdef GOOS_android is more appropriate.

seconded, let's use an ifdef until that proves too unwieldy.

[crawshaw, 2014-07-02 14:57:22]

Thank you both for the careful review. PTAL.

https://codereview.appspot.com/106380043/diff/40001/src/cmd/go/build.go
File src/cmd/go/build.go (right):

https://codereview.appspot.com/106380043/diff/40001/src/cmd/go/build.go#newco...
src/cmd/go/build.go:1745: compiler = append(compiler, "-llog")
On 2014/07/02 04:33:05, dfc wrote:
> On 2014/07/02 04:21:14, minux wrote:
> > put -llog as a #cgo LDFLAGS in runtime/cgo/cgo.go so that
> > we don't need to modify cmd/go for this.
> 
> yup, good idea

Done.

https://codereview.appspot.com/106380043/diff/40001/src/cmd/ld/elf.c
File src/cmd/ld/elf.c (right):

https://codereview.appspot.com/106380043/diff/40001/src/cmd/ld/elf.c#newcode779
src/cmd/ld/elf.c:779: if(strcmp(goos, "android") != 0)
On 2014/07/02 04:33:05, dfc wrote:
> can you use (HEADTYPE == Handroid) here ? 

Confusingly, there is no Handroid. I mapped goos of "android" onto Hlinux.
Probably because I am a bad person.

https://codereview.appspot.com/106380043/diff/40001/src/cmd/ld/pobj.c
File src/cmd/ld/pobj.c (right):

https://codereview.appspot.com/106380043/diff/40001/src/cmd/ld/pobj.c#newcode145
src/cmd/ld/pobj.c:145: if(strcmp(goos, "android") == 0)
On 2014/07/02 04:33:05, dfc wrote:
> if(HEADTYPE == Handroid) maybe
> 
> needs a comment
> 
> // force external linking for android

Done.

> possibly this should be handed by the go tool instead as it controls -linkmode

The other case where cmd/ld changes the linkmode is cmd/ld/link.c:226. I'm not
sure if this is an adequate precedent. I can move it if you prefer.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/os/user/lookup_st...
File src/pkg/os/user/lookup_stubs.go (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/os/user/lookup_st...
src/pkg/os/user/lookup_stubs.go:5: // +build !cgo,!windows,!plan9 android
On 2014/07/02 04:21:14, minux wrote:
> What's your plan for os/user on android?
> 
> do you intent to hardcode a table of uid/username pairs for android?

I intend to use cgo+jni to get to android.os.UserManager and
android.os.Process.myUserHandle. Coming in a (much) later CL.

http://developer.android.com/reference/android/os/UserManager.html

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_arm.s
File src/pkg/runtime/asm_arm.s (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_arm.s...
src/pkg/runtime/asm_arm.s:43: MOVW	g, R0 			// arg 0: G
On 2014/07/02 04:33:05, dfc wrote:
> if you're going to inline setg_gcc, please retain the comment.

sorry, which comment?

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_arm.s...
src/pkg/runtime/asm_arm.s:45: MOVW.NE $runtime·tlsg(SB), R2 	// arg 2: tlsg
On 2014/07/02 04:21:14, minux wrote:
> .NE is unnecessary here.

Done.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_arm.s...
src/pkg/runtime/asm_arm.s:46: MRC     15, 0, R3, C13, C0, 3 	// arg 3: TLS base
pointer
On 2014/07/02 04:21:14, minux wrote:
> because this instruction will be rewritten by the liblink if
> GOARM < 7 to a BL runtime.read_tls_fallback(SB) instruction,
> you have to use R0 for the register here.
> 
> otherwise you will break build for linux/arm with GOARM < 7.
> 
> also note, if you change the argument order, please also keep
> the x_cgo_init function in pkg/runtime/cgo/gcc_{free,net}bsd_arm.c
> up-to-date.
> 
> I will add a explicit check to liblink/obj5.c to diagnose
> this case. (CL 107430044)

thank you, I have been testing exclusively with GOARM=7. I wish there were some
way I could run a CL through all the builders.

bouncing this instruction through R0.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
File src/pkg/runtime/asm_tls_android_arm.s (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
src/pkg/runtime/asm_tls_android_arm.s:5: #include "zasm_GOOS_GOARCH.h"
On 2014/07/02 04:21:14, minux wrote:
> isn't asm_tls_android_arm.s too long?
> I think tls_android_asm.s is perfectly fine.

Done. Both merged into tls_arm.s.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
src/pkg/runtime/asm_tls_android_arm.s:17: MOVW	g, 0(R0)
On 2014/07/02 04:21:14, minux wrote:
> MOVW g, R11<<0(R0)
> instead of ADD and MOVW.
> same below.
> 
> (yeah, the plan 9 arm assembler syntax is weird.
> i hope the new assembler would recognize "R11(R0)")
> 
> should my nacl/arm changes go in first, you will
> need to conditionally use the two-instruction sequence
> just for nacl/arm.

Done.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
File src/pkg/runtime/asm_tls_arm.s (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
src/pkg/runtime/asm_tls_arm.s:12: // m(R9). One reason is that external code
might trigger
On 2014/07/02 04:21:15, minux wrote:
> there is no m(R9) anymore. sync your client with the
> tip please. the comment has already been updated.

Done.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
src/pkg/runtime/asm_tls_arm.s:23: //       runtime.mcall assumes this function
only clobbers R0 and R11.
On 2014/07/02 04:21:14, minux wrote:
> this comment is fairly important, so I strongly suggest we merge
> this file and the other android specific one.

Done.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/asm_tls_a...
src/pkg/runtime/asm_tls_arm.s:29: MOVW	$runtime·tlsg(SB), R11
On 2014/07/02 04:33:05, dfc wrote:
> On 2014/07/02 04:21:15, minux wrote:
> > the difference between this file and the other is small enough so
> > i think using #ifdef GOOS_android is more appropriate.
> 
> seconded, let's use an ifdef until that proves too unwieldy.

Done.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_a...
File src/pkg/runtime/cgo/gcc_android_arm.c (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_a...
src/pkg/runtime/cgo/gcc_android_arm.c:13: // inittls finds the first available
pthread slot and uses it as
On 2014/07/02 04:21:15, minux wrote:
> s/pthread slot/thread-local storage slot/
> 
> see pkg/runtime/cgo/gcc_darwin_386.c for an example of
> this comment.

Done.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_a...
src/pkg/runtime/cgo/gcc_android_arm.c:28: for (i=0; i<50; i++) {
On 2014/07/02 04:21:15, minux wrote:
> probably 50 is too small? darwin/386 tries 128 slots.
> 
> however, too big a number and we might get SIGSEGV/SIGBUS.
> 
> i wonder if we should just use pthread_getspecific in
> load_g and save_g?
> 
> Either way we need to make a few assumptions.
> 1. (your current way) we can read at least N words of TLS without problem and
> tls slots used by other part of the application is less than N.
> 2. (use pthread_getspecific always) it doesn't use much stack space so it can
be
> called from goroutine stack.
> 
> i think 2 is better than 1. what do you think?
> of course, in load_g and save_g we need to save all the caller-save
> registers, but it's not that bad. (we need to save r0-r3, r9, r12, r14)

I'm not comfortable assuming that pthread_getspecific uses little stack space.
There is no promise of that in the bionic API, nor POSIX.

However, good news, bionic tip adds #define PTHREAD_KEYS_MAX, bringing their
pthread implementation a little closer to spec. Sadly it's not in the current
NDK release, so I have added a define and a TODO. Does that seem reasonable?

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_a...
src/pkg/runtime/cgo/gcc_android_arm.c:41: void (*x_cgo_inittls)(void **tlsg,
void **tlsbase) = inittls;
On 2014/07/02 04:21:15, minux wrote:
> i think you can remove the extern declaration here.

Done.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_l...
File src/pkg/runtime/cgo/gcc_linux_arm.c (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_l...
src/pkg/runtime/cgo/gcc_linux_arm.c:39: fprintf(stderr, "runtime/cgo:
pthread_create failed: %s\n", strerror(err));
On 2014/07/02 04:21:15, minux wrote:
> should this message also be sent to __android_log_print?

In a later CL, I intend to intercept runtime.write and make it a cgo call on
android. If fd is 1 or 2, the output will be line buffered and mirrored to
__android_log_print. So this, and many other useful fprintf(stderr) calls
through the runtime will be visible when running from inside an app's shared
library.

[elias.naur, 2014-07-02 16:05:59]

https://codereview.appspot.com/106380043/diff/60001/src/cmd/ld/data.c
File src/cmd/ld/data.c (right):

https://codereview.appspot.com/106380043/diff/60001/src/cmd/ld/data.c#newcode164
src/cmd/ld/data.c:164: if (strcmp(goos, "android") == 0 && r->type == R_TLS)
This looks like performance sensitive code, so perhaps put the cheap check
first: if (r->type == R_TLS && strcmp(goos, "android") == 0)

[minux, 2014-07-02 17:16:54]

https://codereview.appspot.com/106380043/diff/40001/src/cmd/ld/pobj.c
File src/cmd/ld/pobj.c (right):

https://codereview.appspot.com/106380043/diff/40001/src/cmd/ld/pobj.c#newcode145
src/cmd/ld/pobj.c:145: if(strcmp(goos, "android") == 0)
On 2014/07/02 14:57:21, crawshaw wrote:
> The other case where cmd/ld changes the linkmode is cmd/ld/link.c:226. I'm not
> sure if this is an adequate precedent. I can move it if you prefer.
(i think you mean cmd/ld/lib.c)

i think you can move the code to cmd/ld/lib.c so that all special cases are in
one place.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_a...
File src/pkg/runtime/cgo/gcc_android_arm.c (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_a...
src/pkg/runtime/cgo/gcc_android_arm.c:28: for (i=0; i<50; i++) {
On 2014/07/02 14:57:22, crawshaw wrote:
> However, good news, bionic tip adds #define PTHREAD_KEYS_MAX, bringing their
> pthread implementation a little closer to spec. Sadly it's not in the current
> NDK release, so I have added a define and a TODO. Does that seem reasonable?
ok.

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_l...
File src/pkg/runtime/cgo/gcc_linux_arm.c (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_l...
src/pkg/runtime/cgo/gcc_linux_arm.c:39: fprintf(stderr, "runtime/cgo:
pthread_create failed: %s\n", strerror(err));
On 2014/07/02 14:57:22, crawshaw wrote:
> On 2014/07/02 04:21:15, minux wrote:
> > should this message also be sent to __android_log_print?
> 
> In a later CL, I intend to intercept runtime.write and make it a cgo call on
> android. If fd is 1 or 2, the output will be line buffered and mirrored to
> __android_log_print. So this, and many other useful fprintf(stderr) calls
> through the runtime will be visible when running from inside an app's shared
> library.
intercept runtime.write won't intercept calls to fprintf(stderr),
so you still need to do something here.

https://codereview.appspot.com/106380043/diff/60001/src/pkg/runtime/tls_arm.s
File src/pkg/runtime/tls_arm.s (right):

https://codereview.appspot.com/106380043/diff/60001/src/pkg/runtime/tls_arm.s...
src/pkg/runtime/tls_arm.s:14: // Note: all three functions will clobber R0, and
the last
s/three/two. s/R0/R0 and R11/

[crawshaw, 2014-07-02 17:41:42]

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_l...
File src/pkg/runtime/cgo/gcc_linux_arm.c (right):

https://codereview.appspot.com/106380043/diff/40001/src/pkg/runtime/cgo/gcc_l...
src/pkg/runtime/cgo/gcc_linux_arm.c:39: fprintf(stderr, "runtime/cgo:
pthread_create failed: %s\n", strerror(err));
On 2014/07/02 17:16:53, minux wrote:
> intercept runtime.write won't intercept calls to fprintf(stderr),
> so you still need to do something here.

you're right. I'll send a followup CL to introduce an errorf function for the
cgo code that calls __android_log_print on android.

https://codereview.appspot.com/106380043/diff/60001/src/cmd/ld/data.c
File src/cmd/ld/data.c (right):

https://codereview.appspot.com/106380043/diff/60001/src/cmd/ld/data.c#newcode164
src/cmd/ld/data.c:164: if (strcmp(goos, "android") == 0 && r->type == R_TLS)
On 2014/07/02 16:05:59, elias.naur wrote:
> This looks like performance sensitive code, so perhaps put the cheap check
> first: if (r->type == R_TLS && strcmp(goos, "android") == 0)

Done.

https://codereview.appspot.com/106380043/diff/60001/src/pkg/runtime/tls_arm.s
File src/pkg/runtime/tls_arm.s (right):

https://codereview.appspot.com/106380043/diff/60001/src/pkg/runtime/tls_arm.s...
src/pkg/runtime/tls_arm.s:14: // Note: all three functions will clobber R0, and
the last
On 2014/07/02 17:16:54, minux wrote:
> s/three/two. s/R0/R0 and R11/

Done.

[minux, 2014-07-02 18:29:10]

LGTM.

[crawshaw, 2014-07-02 19:06:26]

Thanks! I'll wait a bit before submitting, in case anyone else wants
to chime in.

On Wed, Jul 2, 2014 at 11:28 AM, minux <minux@golang.org> wrote:
> LGTM.

[josharian, 2014-07-02 19:29:18]

> Thanks! I'll wait a bit before submitting, in case anyone else wants
> to chime in.

There's a typo in the CL title. My brain's levenshtein distance minimizer wants
to turn it into emulsion, which is actually not that far off, metaphorically.

[crawshaw, 2014-07-03 20:14:55]

*** Submitted as https://code.google.com/p/go/source/detail?r=d234a6fdf1df ***

cmd/go, cmd/ld, runtime, os/user: TLS emulation for android

Based on cl/69170045 by Elias Naur.

There are currently several schemes for acquiring a TLS
slot to save the g register. None of them appear to work
for android. The closest are linux and darwin.

Linux uses a linker TLS relocation. This is not supported
by the android linker.

Darwin uses a fixed offset, and calls pthread_key_create
until it gets the slot it wants. As the runtime loads
late in the android process lifecycle, after an
arbitrary number of other libraries, we cannot rely on
any particular slot being available.

So we call pthread_key_create, take the first slot we are
given, and put it in runtime.tlsg, which we turn into a
regular variable in cmd/ld.

Makes android/arm cgo binaries work.

LGTM=minux
R=elias.naur, minux, dave, josharian
CC=golang-codereviews
https://codereview.appspot.com/106380043

[gobot, 2014-07-03 20:24:30]

This CL appears to have broken the linux-arm-panda builder.
See http://build.golang.org/log/618d1c7558673c76439472fec9b44d879f324098

[crawshaw, 2014-07-03 20:26:17]

Real, sorry. CL coming.

On Thu, Jul 3, 2014 at 4:24 PM,  <gobot@golang.org> wrote:
> This CL appears to have broken the linux-arm-panda builder.
> See http://build.golang.org/log/618d1c7558673c76439472fec9b44d879f324098
>
> https://codereview.appspot.com/106380043/