misc/cgo/testtls: skip test if C toolchain exhibits known TLS bugs

[mvdan]

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x1b pc=0xe56e4]

runtime stack:
runtime.throw(0x16739f, 0x2a)
	/workdir/go/src/runtime/panic.go:598 +0x54
runtime.sigpanic()
	/workdir/go/src/runtime/signal_unix.go:372 +0x22c

goroutine 5 [syscall, locked to thread]:
runtime.cgocall(0xe5678, 0x429f78, 0xe5208)
	/workdir/go/src/runtime/cgocall.go:128 +0x64 fp=0x429f60 sp=0x429f48 pc=0x123c0
_/workdir/go/misc/cgo/testtls._Cfunc_getTLS(0x0)
	_cgo_gotypes.go:43 +0x38 fp=0x429f74 sp=0x429f60 pc=0xe5134
_/workdir/go/misc/cgo/testtls.testTLS(0x478120)
	/workdir/go/misc/cgo/testtls/tls.go:21 +0x34 fp=0x429fb0 sp=0x429f74 pc=0xe5214
_/workdir/go/misc/cgo/testtls.TestTLS(0x478120)
	/workdir/go/misc/cgo/testtls/tls_test.go:12 +0x1c fp=0x429fb8 sp=0x429fb0 pc=0xe50ec
testing.tRunner(0x478120, 0x168c34)
	/workdir/go/src/testing/testing.go:791 +0xac fp=0x429fe4 sp=0x429fb8 pc=0xb3074
runtime.goexit()
	/workdir/go/src/runtime/asm_arm.s:840 +0x4 fp=0x429fe4 sp=0x429fe4 pc=0x63184
created by testing.(*T).Run
	/workdir/go/src/testing/testing.go:838 +0x240

goroutine 1 [runnable]:
testing.(*T).Run(0x478120, 0x1604a5, 0x7, 0x168c34, 0x410540)
	/workdir/go/src/testing/testing.go:839 +0x260
testing.runTests.func1(0x478090)
	/workdir/go/src/testing/testing.go:1081 +0x50
testing.tRunner(0x478090, 0x44bef8)
	/workdir/go/src/testing/testing.go:791 +0xac
testing.runTests(0x40c040, 0x206598, 0x1, 0x1, 0x458100)
	/workdir/go/src/testing/testing.go:1079 +0x21c
testing.(*M).Run(0x458100, 0x0)
	/workdir/go/src/testing/testing.go:996 +0x134
main.main()
	_testmain.go:42 +0x12c
exit status 2
FAIL	_/workdir/go/misc/cgo/testtls	0.046s

Some recent occurences:

https://build.golang.org/log/b7e1728e48a73089be64d42ea3b7e581eeae029c
https://build.golang.org/log/56a9b6b774c15433baff5b11a2f2eeb8aaa936a1

[josharian]

cc @FiloSottile

Thanks for filing bugs for the flaky tests, @mvdan. Hope we get back to a stable dashboard soon.

[FiloSottile]

This is not my kind of TLS ;) it's Thread Local Storage.

[josharian]

Hahaha. Oops. :P

cc @bcmills @ianlancetaylor

[cherrymui]

The faulting PC, 0xe56e4, is in C code getTLS:

TEXT getTLS(SB) 
  :0                    0xe56d0                 e59f0014                MOVW 0x14(R15), R0      
  :0                    0xe56d4                 e92d4010                PUSH [R4,R14]           
  :0                    0xe56d8                 e08f0000                ADD R0, R15, R0         
  :0                    0xe56dc                 fa001a0a                BLX 0xebf0c             // __tls_get_addr
  :0                    0xe56e0                 e59f3008                MOVW 0x8(R15), R3       
  :0                    0xe56e4                 e7930000                MOVW (R3)(R0), R0       // <--- faulting PC
  :0                    0xe56e8                 e8bd8010                POP [R4,R15]            
  :0                    0xe56ec                 00120938                AND.S.EQ R8>>R9, R2, R0 
  :0                    0xe56f0                 0000001c                AND.EQ R12<<R0, R0, R0  

Here, we just loaded R3=0x1c from the constant pool. The faulting address is 0x1b, which means R0=-1, which means __tls_get_addr returned -1. I haven't looked into what could cause it. Maybe the TLS was not initialized correctly?

[ianlancetaylor]

2018-04-06T23:03:41-31db81d/linux-arm
2018-04-07T08:29:15-cd682f3/linux-arm
2018-04-09T19:41:38-53c8f61/linux-arm
2018-04-14T13:55:29-77faa65/linux-arm
2018-05-02T17:52:14-e8d417d/linux-arm
2018-05-06T13:53:47-260ae19/linux-arm
2018-05-30T13:40:36-e023d5b/linux-arm

[ianlancetaylor]

2018-06-17T08:48:39-05f8b44/linux-arm
2018-06-20T18:43:22-ee9c939/linux-arm

[bcmills]

https://build.golang.org/log/29aec0ed049250f35242081dc462c98fffe1deb6