all: support netbsd/arm64 #30824
I can see two problems,
(1) By code inspection, nothing seems to set TLS.
(2) broken signal handling. if I send SIGINFO (^T), it usually segfaults,
here g.m=NULL. I guess g is invalid.
The code for that is the runtime.sig* functions. It's probably just wrong and not exercised by other things.
let's just move this to linux?
made #31583 for this
Where/when possible Go will use a dedicated register rather than using TLS - in the case of arm64, this is register R28 (g). If cgo is used then the resulting binary has a PT_TLS segment and the dynamic loader (ld.so) is usually responsible for allocating and setting up TLS, which can then be used by the thread. In the case of cgo the g register is still used, however there are known points where we have to reload it from TLS.
The main reason for this is that the NetBSD kernel trashes the g register, by storing a pointer to the ucontext in R28 (in addition to R2) - see
At first glance, in the non-cgo case we may be able to be somewhat "clever" and reload g from the mcontext, since it should match what we had previously. Otherwise it would need to use a similar set up to what amd64 does - use
referenced this issue
May 22, 2019
So I tried a test run on a real machine, a Raspberry Pi 3 running NetBSD-current in 64-bit mode.
Other invocations of the go tool that I tried fail in the same way. Here are full outputs of backtraces from gdb and
The relevant bits are, I think:
Note that line 248 is in the implementation of