all: port to Windows/ARM32

[jordanrh1]

Hi everyone, we will be submitting a patch in the near future that adds Windows/ARM32 support to GO. All but a few tests are passing, and this implementation has been used to compile GO itself and run Docker containers on Windows/ARM32. We look forward to working with the community to iron out the last remaining issues and get this merged!

[cznic]

I'm curious why was the port developed out-of-tree? I'm asking because I'm afraid it's much more complicated to properly review such a big change, as an port to new architecture is, in a single CL.

In any case, please check https://github.com/golang/go/blob/master/CONTRIBUTING.md and the linked from there https://golang.org/doc/contribute.html for more details.

(Personal wish: Please spell the name of the language as 'Go'.)

[alexbrainman]

@jordanrh1 you should read https://github.com/golang/go/wiki/PortingPolicy

Alex

[jordanrh1]

@cznic We were under a tight deadline and did not know if it was feasible. This is the earliest I could engage the community. We can break down the change into smaller chunks if necessary.

@alexbrainman Thanks for the link. We are committed to meeting the requirements outlined in the doc.

[alexbrainman]

We are committed to meeting the requirements outlined in the doc.

SGTM.

Alex

[gopherbot]

Change https://golang.org/cl/125643 mentions this issue: dashboard: add windows-arm builder

[gopherbot]

Change https://golang.org/cl/125648 mentions this issue: cmd/link: support windows/arm

[gopherbot]

Change https://golang.org/cl/125649 mentions this issue: debug/pe: support windows/arm

[gopherbot]

Change https://golang.org/cl/125645 mentions this issue: runtime: add definitions for windows/arm

[gopherbot]

Change https://golang.org/cl/125647 mentions this issue: cmd/api: support windows/arm

[gopherbot]

Change https://golang.org/cl/125646 mentions this issue: cmd/dist: support windows/arm

[gopherbot]

Change https://golang.org/cl/128715 mentions this issue: runtime: support windows/arm

[gopherbot]

Change https://golang.org/cl/128716 mentions this issue: syscall: support windows/arm

[gopherbot]

Change https://golang.org/cl/130056 mentions this issue: cmd/dist: support windows/arm

[gopherbot]

Change https://golang.org/cl/131282 mentions this issue: cmd/vet: remove exclusions for callbackasm

[gopherbot]

Change https://golang.org/cl/127665 mentions this issue: windows: add support for windows/arm

[jordanrh1]

Exciting stuff:

[petemoore]

@jordanrh1 Is there an issue for porting to Windows/ARM64 too? Thanks.

[jordanrh1]

@petemoore There is not.

[0xacf]

It seems exes built with GOOS=windows GOARCH=arm with the current master won't run on Windows RT 8.1, failing with "This app can't run on your PC". This is with code signature checking subverted. I haven't looked into it yet so I'm unsure of details and I know this platform is out of support, but is this a configuration that theoretically should be working? By the way, fantastic work.

[jordanrh1]

You also need to specify GOARM=7. I'll look into whether there's a way to do this by default.

[0xacf]

Unfortunately it's still failing with the same error. I made sure to clear the Go build cache and delete the output .exe, so I'm fairly sure it is getting rebuilt properly. I've put my test file / command below.

$ cat hello.go
package main

import "fmt"

func main() {
  fmt.Println("hello, world")
}

$ GOOS=windows GOARCH=arm GOARM=7 ./go/bin/go build hello.go

[jordanrh1]

If you have time, try starting it under the usermode debugger, and see if it offers any clues:

windbg.exe hello.exe

If it fails to start, then it's probably being rejected by the loader. To troubleshoot loader errors, connect kernel debugger and turn on loader snaps,

!gflag +sls

Then try running the program. Loader spew will be printed to the windbg window.

[0xacf]

I definitely have time to do some tests and try to fix this, but likewise, don't worry about this platform too much if nobody considers it important!

Unfortunately it appears security restrictions in Windows RT prevent the debugger from creating or attaching to processes. If you know of any other way to get log messages out of the linker / loader I'll happily try that, otherwise I'll reply later if I end up getting the debugger working somehow.

Edit: Running the program a different way, I can see it produces ERROR_BAD_EXE_FORMAT (%1 is not a valid Win32 application.)

[alexbrainman]

@jordanrh1 I managed to run windows-arm on one of my RPIs. The only bits I am still missing is git command. What do you do for git on windows-arm?

@bradfitz is there a git command that is written in pure Go? I would just compile it to windows-arm and use it there. I would not need anything fancy, just basic git functionality.

Thank you.

Alex

[bradfitz]

@alexbrainman, the builders don't use git. They only run the x/build/cmd/buildlet binary and the cmd/coordinator pushes code in tarballs at them.

[alexbrainman]

@alexbrainman, the builders don't use git.

Fair enough. I suppose I have to find a way to develop on this thing.

Alex

[jordanrh1]

I do all my development on linux and cross compile to windows/arm.

[alexbrainman]

I do all my development on linux and cross compile to windows/arm.

I do too.

But I was trying to fix #30711. And that involved running cmd/go.TestScript, and cmd/go.TestScript runs go.exe executable. So I needed all moving parts. I used $GOROOT/src/bootstrap.bash (luckily for me it worked without a hitch) to create a snapshot of current Go tree with executables and built packages, and copied all these files onto RPI. And then run the test.

I did not have Git, so I had to be careful when changing files to fix #30711. The fix was small enough for me to manage without Git. But I would not use that setup for anything bigger than that.

RPI runs standard Windows file and printer sharing services, and I was able to mount shares from RPI on my Windows PC. Maybe (I did not try that) I could just use Git on my Windows PC to manage Go repo installed on RPI. I will see next time I use that.

Another thing. While debugging, I searched for windows-arm prebuilt image on https://golang.org/dl and it is not there. @bradfitz maybe we should put latest windows-arm image at https://golang.org/dl. I doubt there is need for ,msi file, but we should put .zip file alongside with 386 and amd64.

Also @jordanrh1 I struggled to make Windows 10 running on some of my RPIs.

I have RPI 3 B+. I downloaded "IoT Dashboard", and it gives me option of installing "Windows 10 IoT Core (17763)". I created SD card (ScanDisk Ultra 16GB), but RPI does not boot - red power light comes on, and I get rainbow image on my HDMI screen, but nothing happens.

I also have RPI 2 B. I tried booting this with the same image - red light is on, green light flashes 4 slow times followed by 4 quick times, same rainbow image on the screen.

I managed to run Windows on RPI 3 B. But I would like to make my other RPIs run Windows. Do you have any suggestions?

Also I noticed that windows-arm builder is not listed on https://build.golang.org Can you, please, investigate what happened to it?

I also wonder, if we could run windows-arm build on multiple RPI devices to make it faster?

Maybe we could even run it on virtual hardware (crazy idea). Like

https://www.newventuresoftware.com/blog/running-windows-10-iot-core-in-a-virtual-machine

or

https://stackoverflow.com/questions/30276610/how-to-deploy-windows-10-iot-rasp-pi-image-as-a-virtual-machine

Thank you.

Alex

[bcmills]

@jordanrh1, per http://golang.org/wiki/PortingPolicy#requirements-for-a-new-port, “[t]he builder must already be running” for new ports. I don't see any results for the windows-arm builder on https://build.golang.org since March 20.

Has this port been abandoned?

[mirogl]

Hi - there is already a port available at https://github.com/thongtech/go-windows-arm64 - does this help ?