all: support netbsd/arm64 #30824

coypoop · 2019-03-14T03:18:38Z

Tracking progress of netbsd/arm64 support:

#29398 adds support, not completely functional.
A simple program (hello world) runs, getting further and trying to build Go itself fails.

gopherbot · 2019-03-14T04:19:46Z

Change https://golang.org/cl/155739 mentions this issue: all: add netbsd/arm64 support

bradfitz · 2019-03-14T04:20:04Z

What's the plan for a builder?

See https://golang.org/wiki/PortingPolicy

bsiegert · 2019-03-14T11:59:16Z

We can run a builder on Scaleway, with the caveat that there needs to be a working builder binary first :)

Otherwise, I could contribute a builder on real hardware; I have an arm64 machine running NetBSD.

bradfitz · 2019-03-14T20:38:42Z

We can run a builder on Scaleway, with the caveat that there needs to be a working builder binary first :)

Oh, does NetBSD boot on Scaleway ARM64 instances? I never had much luck with non-Linux OSes on Scaleway.

coypoop · 2019-03-15T11:21:19Z

I can see two problems,

(1) By code inspection, nothing seems to set TLS.
netbsd/amd64 does it with a lwp_setprivate(m->tls) syscall in lwp_tramp.
I am new to TLS so I want to see effects to my changes so I am holding onto that change until I see it affecting something.

(2) broken signal handling. if I send SIGINFO (^T), it usually segfaults,

Thread 3 received signal SIGSEGV, Segmentation fault.
0x000000000004e2b4 in runtime.sigtrampgo (sig=<optimized out>, info=0x4000449bd0, ctx=0x4000449c50) at /home/fly/go/src/runtime/signal_unix.go:307
307             if sp < g.m.gsignal.stack.lo || sp >= g.m.gsignal.stack.hi {
(gdb) bt
#0  0x000000000004e2b4 in runtime.sigtrampgo (sig=<optimized out>, info=0x4000449bd0, ctx=0x4000449c50) at /home/fly/go/src/runtime/signal_unix.go:307
#1  0x00000000000640ec in runtime.sigtramp () at /home/fly/go/src/runtime/sys_netbsd_arm64.s:297
#2  0x0000000000064060 in runtime.sigprocmask () at /home/fly/go/src/runtime/sys_netbsd_arm64.s:253
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

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.

coypoop · 2019-04-20T11:23:15Z

../cmd/vet/all/whitelist/darwin_arm.txt
5:runtime/asm_arm.s: [arm] sigreturn: function sigreturn missing Go declaration
../cmd/vet/all/whitelist/darwin_arm64.txt
3:runtime/asm_arm64.s: [arm64] sigreturn: function sigreturn missing Go declaration
../cmd/vet/all/whitelist/freebsd_arm.txt
3:runtime/asm_arm.s: [arm] sigreturn: function sigreturn missing Go declaration

let's just move this to linux?

made #31583 for this

bsiegert · 2019-04-20T14:09:16Z

This works well enough to run some code natively on arm64, but not well enough for more complicated code. I've been suggested to start a pull request anyway. Updates #30824 Change-Id: Ib4f63e0e8a9edfc862cf65b5f1b0fbf9a8a1628e GitHub-Last-Rev: b01b105 GitHub-Pull-Request: #29398 Reviewed-on: https://go-review.googlesource.com/c/go/+/155739 Run-TryBot: Benny Siegert <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Benny Siegert <[email protected]>

gopherbot · 2019-04-26T13:42:39Z

Change https://golang.org/cl/174078 mentions this issue: runtime: gofmt defs1_netbsd_arm64.go

Updates #30824 Change-Id: I3d9ad7896d528d8274ec78378a546b0356986b9d Reviewed-on: https://go-review.googlesource.com/c/go/+/174078 Reviewed-by: Brad Fitzpatrick <[email protected]>

gopherbot · 2019-05-04T09:38:20Z

Change https://golang.org/cl/175237 mentions this issue: syscall: support generating netbsd/arm64 files in mkall.sh

CL 155739 added the generated files but didn't update mkall.sh. Do so now. Updates #30824 Change-Id: I642bbff6afbc976091a0dc291fa2beff5e245246 Reviewed-on: https://go-review.googlesource.com/c/go/+/175237 Reviewed-by: Brad Fitzpatrick <[email protected]> Reviewed-by: Benny Siegert <[email protected]> Run-TryBot: Benny Siegert <[email protected]> Run-TryBot: Tobias Klauser <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>

gopherbot · 2019-05-14T19:28:03Z

Change https://golang.org/cl/177120 mentions this issue: runtime: fix netbsd/arm64 assembly

4a6f656c · 2019-05-15T18:33:56Z

(1) By code inspection, nothing seems to set TLS.
netbsd/amd64 does it with a lwp_setprivate(m->tls) syscall in lwp_tramp.
I am new to TLS so I want to see effects to my changes so I am holding onto that change until I see it affecting something.

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.

(2) broken signal handling. if I send SIGINFO (^T), it usually segfaults,

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 /* put in callee save register */ comment in:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/aarch64/aarch64/sig_machdep.c?rev=1.1.28.2&content-type=text/x-cvsweb-markup

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 lwp_setprivate to set the TLS pointer to m_tls and then load_g and save_g through TLS (which will be somewhat of a performance hit).

Fix various bugs in the netbsd/arm64 runtime assembly. Updates #30824. Change-Id: I5ca10926ab663a8ff4df9973530e645e2469c1aa Reviewed-on: https://go-review.googlesource.com/c/go/+/177120 Reviewed-by: Benny Siegert <[email protected]> Reviewed-by: Cherry Zhang <[email protected]> Run-TryBot: Benny Siegert <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>

tklauser · 2019-05-21T10:03:32Z

While reading through some code I noticed https://golang.org/cl/174129 and its related issue #31746 regarding CPU feature detection on openbsd/arm64. Does netbsd/arm64 need a similar mechanism as well? Or does it provide CPU feature detection via AT_HWCAP?

coypoop · 2019-05-22T17:48:05Z

netbsd doesn't supply AT_HWCAP either, but it does have a bunch of sysctls. I wonder how bad it will be to just provide AT_HWCAP.

gopherbot · 2019-06-03T08:56:05Z

Change https://golang.org/cl/179939 mentions this issue: internal/socket: add support for netbsd/arm64

Updates golang/go#30824 Change-Id: I872b725d6640e29570652171b6c45634fc21a461 Reviewed-on: https://go-review.googlesource.com/c/net/+/179939 Run-TryBot: Tobias Klauser <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Benny Siegert <[email protected]>

bsiegert · 2019-06-15T19:38:08Z

So I tried a test run on a real machine, a Raspberry Pi 3 running NetBSD-current in 64-bit mode.

$ go env
Memory fault (core dumped)

Other invocations of the go tool that I tried fail in the same way. Here are full outputs of backtraces from gdb and ktrace:

gdb.txt
kdump.txt

The relevant bits are, I think:

   418      5 go       PSIG  SIGCHLD caught handler=0x644c0 mask=(): code=CLD_EXITED child pid=1828, uid=1000,  status=1, utime=0, stime=0)
   418      1 go       RET   __wait450 1828/0x724
   418      5 go       PSIG  SIGSEGV SIG_DFL: code=SEGV_MAPERR, addr=0x50, trap=-1845493753)

And:

Thread 1 (process 9):
#0  0x000000000004e3e4 in runtime.sigtrampgo (sig=<optimized out>, info=0x4000239bd0, ctx=0x4000239c50) at /usr/local/go/src/runtime/signal_unix.go:308
#1  0x0000000000064538 in runtime.sigtramp () at /usr/local/go/src/runtime/sys_netbsd_arm64.s:314
#2  0x0000000000064460 in runtime.sigprocmask () at /usr/local/go/src/runtime/sys_netbsd_arm64.s:248

Note that line 248 is in the implementation of runtime·sigprocmask, in the failure handler which deliberately references a null pointer to provoke a crash.

@coypoop @tklauser Any ideas?

4a6f656c · 2019-06-16T19:31:52Z

@bsiegert - signal handling is currently completely broken, since the kernel trashes the g register (see my earlier #30824 (comment) for details).

gopherbot · 2019-09-03T13:48:43Z

Change https://golang.org/cl/192998 mentions this issue: [release-branch.go1.13] doc/go1.13: remove announcements of arm64 support on NetBSD and OpenBSD

…port on NetBSD and OpenBSD Those configurations currently lack builders, and it is not clear to me what state their tests are in. The Go porting policy¹ requires builders for all active ports, so let's not claim support until that requirement is met. ¹https://golang.org/wiki/PortingPolicy#requirements-for-a-new-port Updates #30824 Updates #31656 Updates #34035 Updates #34036 Change-Id: I6496de9d92fb8546048abf139cf10546a47e314b Reviewed-on: https://go-review.googlesource.com/c/go/+/192997 Reviewed-by: Dmitri Shuralyov <[email protected]> (cherry picked from commit 9f5127b) Reviewed-on: https://go-review.googlesource.com/c/go/+/192998 Run-TryBot: Bryan C. Mills <[email protected]>

Those configurations currently lack builders, and it is not clear to me what state their tests are in. The Go porting policy¹ requires builders for all active ports, so let's not claim support until that requirement is met. ¹https://golang.org/wiki/PortingPolicy#requirements-for-a-new-port Updates golang#30824 Updates golang#31656 Updates golang#34035 Updates golang#34036 Change-Id: I6496de9d92fb8546048abf139cf10546a47e314b Reviewed-on: https://go-review.googlesource.com/c/go/+/192997 Reviewed-by: Dmitri Shuralyov <[email protected]>

bsiegert · 2020-05-22T18:50:15Z

There are some local patches in the pkgsrc repository that make Go actually work on netbsd/arm64. Would these patches be accepted during the freeze? It would be awesome if we could get arm64 support as part of Go 1.15.

gopherbot · 2020-05-23T18:39:50Z

Change https://golang.org/cl/235097 mentions this issue: cpu: avoid illegal instruction on netbsd/arm64

On NetBSD, this package tries to read a privileged register, which results in a SIGILL. Use the same workaround as Android and iOS. In the future, we could use sysctl(3) instead. Update golang/go#30824 Change-Id: Ifd9aa2a2cf4dac43341d013602d1ccb4b8d6eb6d Reviewed-on: https://go-review.googlesource.com/c/sys/+/235097 Reviewed-by: Tobias Klauser <[email protected]> Run-TryBot: Tobias Klauser <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>

gopherbot · 2020-06-08T15:53:31Z

Change https://golang.org/cl/231957 mentions this issue: runtime: use hw.ncpuonline sysctl in getncpu on netbsd

andybons · 2020-06-08T16:42:56Z

Would these patches be accepted during the freeze? It would be awesome if we could get arm64 support as part of Go 1.15.

I’d rather we not land anything in the tree this far into the freeze. Sorry.

Since NetBSD 7, hw.ncpuonline reports the number of CPUs online, while hw.cpu reports the number of CPUs configured. Try hw.cpuonline first and fall back to hw.ncpu in case it fails (which is the case on NetBSD before 7.0). This follows the behavior on OpenBSD (see CL 161757). Also, Go in pkgsrc is patched to use hw.cpuonline, so this CL would allow said patch to be dropped. Updates #30824 Change-Id: Id1c19dff2c1e4401e6074179fae7c708ba0e3098 Reviewed-on: https://go-review.googlesource.com/c/go/+/231957 Run-TryBot: Tobias Klauser <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Reviewed-by: Benny Siegert <[email protected]>

gopherbot · 2020-09-26T17:23:02Z

Change https://golang.org/cl/257643 mentions this issue: cmd/dist: detect gohostarch on netbsd/arm64 hosts

On netbsd/arm64 `uname -m` reports `evbarm` which is mapped to gohostarch=arm. Fix this by checking for "aarch64" in `uname -p` output to fix self-hosted build on netbsd/arm64. Updates #30824 Change-Id: I0f0450ff35af0bec51aeec3b210143ba892216c6 Reviewed-on: https://go-review.googlesource.com/c/go/+/257643 Trust: Tobias Klauser <[email protected]> Trust: Benny Siegert <[email protected]> Run-TryBot: Tobias Klauser <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Benny Siegert <[email protected]>

gopherbot · 2020-09-26T19:49:39Z

Change https://golang.org/cl/257645 mentions this issue: runtime: fix stack alignment for pipe2 return value on netbsd-arm64

Add missing declaration of crosscall1. Fix stack alignment for pipe2 return value. Work around kernel clobbering of r28 on aarch64 by reloading from ucontext. https://nxr.netbsd.org/xref/src/sys/arch/aarch64/aarch64/sig_machdep.c#104 Update #30824 Change-Id: I7f9472939f4c02953f8c207308610118f5d3c54c Reviewed-on: https://go-review.googlesource.com/c/go/+/257645 Reviewed-by: Ian Lance Taylor <[email protected]> Trust: Benny Siegert <[email protected]>

gopherbot · 2020-09-28T08:30:20Z

Change https://golang.org/cl/257938 mentions this issue: dashboard: only build tip on netbsd-arm64-bsiegert builder

gopherbot · 2020-09-28T09:21:28Z

Change https://golang.org/cl/257998 mentions this issue: runtime: initialise cpu.HWCap on netbsd/arm64

NetBSD does not supply AT_HWCAP, however we still need to initialise cpu.HWCaps. For now specify the bare minimum until we add some form of capabilities detection. See https://golang.org/issue/30824#issuecomment-494901591 Follows CL 174129 which did the same for openbsd/arm64. Updates #30824 Change-Id: I43a86b583bc60d259a66772703de06970124bb7f Reviewed-on: https://go-review.googlesource.com/c/go/+/257998 Trust: Tobias Klauser <[email protected]> Trust: Benny Siegert <[email protected]> Run-TryBot: Tobias Klauser <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Reviewed-by: Benny Siegert <[email protected]> TryBot-Result: Go Bot <[email protected]>

The build fails on 1.15 and earlier. Updates golang/go#30824 Change-Id: I1f62d37cc05dde988cbb7e5124bd97916b38bcb3 Reviewed-on: https://go-review.googlesource.com/c/build/+/257938 Trust: Tobias Klauser <[email protected]> Trust: Benny Siegert <[email protected]> Run-TryBot: Tobias Klauser <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Benny Siegert <[email protected]>

gopherbot · 2020-09-29T15:18:47Z

Change https://golang.org/cl/258000 mentions this issue: runtime: correct arguments to pipe2 syscall in pipe

Follow the implementation of pipe2 to pass arguments and handle return values. With this fix the runtime tests pass on netbsd/arm64 (tested using gomote on the netbsd-arm64-bsiegert builder). Update #30824 Change-Id: I346db68fc9dde8dc7f11351af05c1ad3105f4a32 Reviewed-on: https://go-review.googlesource.com/c/go/+/258000 Trust: Tobias Klauser <[email protected]> Trust: Benny Siegert <[email protected]> Run-TryBot: Tobias Klauser <[email protected]> Reviewed-by: Benny Siegert <[email protected]> TryBot-Result: Go Bot <[email protected]>

bsiegert · 2020-09-30T06:29:43Z

So with the last change, we finally seem to have a builder that finishes with an "ok" status. Thanks everyone for this achievement!

gopherbot · 2020-10-02T20:13:56Z

Change https://golang.org/cl/259277 mentions this issue: doc/go1.16: announce netbsd/arm64 support

netbsd/arm64 now complies with all the requirements for a port as specified on https://golang.org/wiki/PortingPolicy Note that this was preliminarily announced in the Go 1.13 release notes (CL 183637) but then removed again due to the port lacking a builder at that time (CL 192997). Updates #30824 Change-Id: I2f40fabc84fe9cb699282e6a9d13ed9b64478e36 Reviewed-on: https://go-review.googlesource.com/c/go/+/259277 Trust: Tobias Klauser <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>

4a6f656c · 2020-12-07T17:55:32Z

Per #42422, this port still appears to be unstable.

tklauser · 2022-03-25T23:54:15Z

netbsd/arm64 is supported since Go 1.16 and the builder seems to run stable since #42422 was resolved. I think this can be closed.

bradfitz changed the title ~~netbsd/arm64 support~~ all: support netbsd/arm64 Mar 14, 2019

coypoop mentioned this issue Mar 14, 2019

all: add start of netbsd/arm64 support #29398

Closed

bradfitz added the OS-NetBSD label Mar 14, 2019

bradfitz added this to the Go1.13 milestone Mar 14, 2019

bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. FeatureRequest Issues asking for a new feature that does not need a proposal. labels Apr 12, 2019

gopherbot pushed a commit that referenced this issue Apr 26, 2019

runtime: gofmt defs1_netbsd_arm64.go

bc48cc7

Updates #30824 Change-Id: I3d9ad7896d528d8274ec78378a546b0356986b9d Reviewed-on: https://go-review.googlesource.com/c/go/+/174078 Reviewed-by: Brad Fitzpatrick <[email protected]>

tklauser mentioned this issue May 22, 2019

internal/cpu: implement CPU capability detection for openbsd/arm64 #31746

Closed

andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019

rsc modified the milestones: Go1.14, Backlog Oct 9, 2019

dmitshur added the arch-arm64 label Aug 16, 2020

tklauser closed this as completed Mar 25, 2022

golang locked and limited conversation to collaborators Mar 26, 2023

gopherbot added the FrozenDueToAge label Mar 26, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

all: support netbsd/arm64 #30824

all: support netbsd/arm64 #30824

coypoop commented Mar 14, 2019

gopherbot commented Mar 14, 2019

bradfitz commented Mar 14, 2019

bsiegert commented Mar 14, 2019

bradfitz commented Mar 14, 2019

coypoop commented Mar 15, 2019

coypoop commented Apr 20, 2019 •

edited

Loading

bsiegert commented Apr 20, 2019 via email

gopherbot commented Apr 26, 2019

gopherbot commented May 4, 2019

gopherbot commented May 14, 2019

4a6f656c commented May 15, 2019

tklauser commented May 21, 2019

coypoop commented May 22, 2019

gopherbot commented Jun 3, 2019

bsiegert commented Jun 15, 2019

4a6f656c commented Jun 16, 2019 •

edited

Loading

gopherbot commented Sep 3, 2019

bsiegert commented May 22, 2020

gopherbot commented May 23, 2020

gopherbot commented Jun 8, 2020

andybons commented Jun 8, 2020

gopherbot commented Sep 26, 2020

gopherbot commented Sep 26, 2020

gopherbot commented Sep 28, 2020

gopherbot commented Sep 28, 2020

gopherbot commented Sep 29, 2020

bsiegert commented Sep 30, 2020

gopherbot commented Oct 2, 2020

4a6f656c commented Dec 7, 2020

tklauser commented Mar 25, 2022 •

edited

Loading

all: support netbsd/arm64 #30824

all: support netbsd/arm64 #30824

Comments

coypoop commented Mar 14, 2019

gopherbot commented Mar 14, 2019

bradfitz commented Mar 14, 2019

bsiegert commented Mar 14, 2019

bradfitz commented Mar 14, 2019

coypoop commented Mar 15, 2019

coypoop commented Apr 20, 2019 • edited Loading

bsiegert commented Apr 20, 2019 via email

gopherbot commented Apr 26, 2019

gopherbot commented May 4, 2019

gopherbot commented May 14, 2019

4a6f656c commented May 15, 2019

tklauser commented May 21, 2019

coypoop commented May 22, 2019

gopherbot commented Jun 3, 2019

bsiegert commented Jun 15, 2019

4a6f656c commented Jun 16, 2019 • edited Loading

gopherbot commented Sep 3, 2019

bsiegert commented May 22, 2020

gopherbot commented May 23, 2020

gopherbot commented Jun 8, 2020

andybons commented Jun 8, 2020

gopherbot commented Sep 26, 2020

gopherbot commented Sep 26, 2020

gopherbot commented Sep 28, 2020

gopherbot commented Sep 28, 2020

gopherbot commented Sep 29, 2020

bsiegert commented Sep 30, 2020

gopherbot commented Oct 2, 2020

4a6f656c commented Dec 7, 2020

tklauser commented Mar 25, 2022 • edited Loading

coypoop commented Apr 20, 2019 •

edited

Loading

4a6f656c commented Jun 16, 2019 •

edited

Loading

tklauser commented Mar 25, 2022 •

edited

Loading