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 · 5 comments

Comments

Projects
None yet
4 participants
@coypoop
Copy link

coypoop 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

gopherbot 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

bradfitz 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

bsiegert 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

bradfitz 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
Author

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

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.