Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all: support netbsd/arm64 #30824

Open
coypoop opened this issue Mar 14, 2019 · 16 comments

Comments

Projects
None yet
8 participants
@coypoop
Copy link
Contributor

commented Mar 14, 2019

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.

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

@bradfitz bradfitz added the OS-NetBSD label Mar 14, 2019

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

@gopherbot

This comment has been minimized.

Copy link

commented Mar 14, 2019

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

@bradfitz

This comment has been minimized.

Copy link
Member

commented Mar 14, 2019

What's the plan for a builder?

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

@bsiegert

This comment has been minimized.

Copy link
Contributor

commented Mar 14, 2019

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

This comment has been minimized.

Copy link
Member

commented Mar 14, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 15, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 20, 2019

../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

This comment has been minimized.

Copy link
Contributor

commented Apr 20, 2019

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

all: add start of netbsd/arm64 support
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 <bsiegert@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
@gopherbot

This comment has been minimized.

Copy link

commented Apr 26, 2019

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

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

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 <bradfitz@golang.org>
@gopherbot

This comment has been minimized.

Copy link

commented May 4, 2019

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

gopherbot pushed a commit that referenced this issue May 5, 2019

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 <bradfitz@golang.org>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@gopherbot

This comment has been minimized.

Copy link

commented May 14, 2019

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

@4a6f656c

This comment has been minimized.

Copy link
Contributor

commented May 15, 2019

(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).

gopherbot pushed a commit that referenced this issue May 17, 2019

runtime: fix netbsd/arm64 assembly
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 <bsiegert@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@tklauser

This comment has been minimized.

Copy link
Member

commented May 21, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented May 22, 2019

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

This comment has been minimized.

Copy link

commented Jun 3, 2019

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

gopherbot pushed a commit to golang/net that referenced this issue Jun 3, 2019

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 <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
@bsiegert

This comment has been minimized.

Copy link
Contributor

commented Jun 15, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 16, 2019

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.