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: port to Windows/ARM32 #26148

Open
jordanrh1 opened this issue Jun 29, 2018 · 62 comments
Open

all: port to Windows/ARM32 #26148

jordanrh1 opened this issue Jun 29, 2018 · 62 comments

Comments

@jordanrh1
Copy link
Contributor

@jordanrh1 jordanrh1 commented Jun 29, 2018

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
Copy link
Contributor

@cznic cznic commented Jun 29, 2018

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

@bcmills bcmills added this to the Unplanned milestone Jun 29, 2018
@jordanrh1
Copy link
Contributor Author

@jordanrh1 jordanrh1 commented Jun 30, 2018

@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
Copy link
Member

@alexbrainman alexbrainman commented Jun 30, 2018

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

SGTM.

Alex

@agnivade agnivade changed the title Porting GO to Windows/ARM32 all: port to Windows/ARM32 Jun 30, 2018
@ALTree ALTree added the OS-Windows label Jul 10, 2018
@gopherbot
Copy link

@gopherbot gopherbot commented Jul 24, 2018

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

gopherbot pushed a commit to golang/build that referenced this issue Jul 24, 2018
Updates golang/go#26148

Change-Id: I23a2c7bd1c2f8f7c960aaedfe0dcdee4e11825ab
Reviewed-on: https://go-review.googlesource.com/125643
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Jul 24, 2018

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

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 24, 2018

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

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 24, 2018

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

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 24, 2018

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

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 24, 2018

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

@gopherbot
Copy link

@gopherbot gopherbot commented Aug 8, 2018

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

@gopherbot
Copy link

@gopherbot gopherbot commented Aug 8, 2018

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

@bradfitz bradfitz modified the milestones: Unplanned, Go1.12 Aug 14, 2018
gopherbot pushed a commit that referenced this issue Aug 20, 2018
Updates #26148

Change-Id: I407481f9c0f8e3565dcfcbbc53e5aa7427d74680
Reviewed-on: https://go-review.googlesource.com/125646
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
gopherbot pushed a commit that referenced this issue Aug 20, 2018
Enable 'go tool objdump' to disassemble windows/arm images.

Updates #26148

Change-Id: I7d11226f01d92288061f8e25980334b9bd82c41f
Reviewed-on: https://go-review.googlesource.com/125649
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Aug 20, 2018

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

gopherbot pushed a commit that referenced this issue Aug 20, 2018
Updates #26148

Change-Id: I4744ebcc77fda3acc1301a1d8857754c0ee797fa
Reviewed-on: https://go-review.googlesource.com/130056
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
gopherbot pushed a commit that referenced this issue Aug 21, 2018
Enable the Go linker to generate executables for windows/arm.

Generates PE relocation tables, which are used by Windows to
dynamically relocate the Go binary in memory. Windows on ARM
requires all modules to be relocatable, unlike x86/amd64 which are
permitted to have fixed base addresses.

Updates #26148

Change-Id: Ie63964ff52c2377e121b2885e9d05ec3ed8dc1cd
Reviewed-on: https://go-review.googlesource.com/125648
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
gopherbot pushed a commit that referenced this issue Aug 22, 2018
Updates #26148

Change-Id: I008502232642237270b7c8a2efb4a378345d06fd
Reviewed-on: https://go-review.googlesource.com/128716
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Aug 24, 2018

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

gopherbot pushed a commit that referenced this issue Sep 18, 2018
Updates #26148

Change-Id: I8f68b2c926c7b11dc86c9664ed7ff2d2f78b64b4
Reviewed-on: https://go-review.googlesource.com/128715
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Sep 24, 2018

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

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Dec 28, 2018

I'm not sure there's a way to ensure that C code which relies on SEH or C++ exceptions has a chance to clean up in case of a go panic.

I agree. This is not implemented, and it won't be simple to implement.

It seems best to recover() in the callback, and not panic across callback boundaries.

I agree in general, but I don't think it is acceptable for our runtime tests. I think Go users write code that panics from callback and into call site function. We should try and make it work, if possible.

Another option is to find a replacement for EnumWindows that is safe to panic across and use that for the test instead

That sounds good. I don't remember who came up with EnumWindows to test it all, but anything else should be fine too. As long as it works and easily available on any Windows computer that is supported by Go.

Alex

@jordanrh1
Copy link
Contributor Author

@jordanrh1 jordanrh1 commented Dec 29, 2018

@ianlancetaylor One of the reasons it doesn't readily manifest on amd64/386 is that amd64/386 tests run on Windows Desktop, which has a different implementation of user32 than IoT Core, which is where the ARM tests run. Iot Core uses 'minuser', which is a completely rewritten window manager. I was able to reproduce the exact crash on AMD64 by running the test on IoT Core. In the deferral, I called a function that used a large chunk of g0 stack (in a legal way), to ensure that any stack based data structures still referenced would be overwritten with garbage data. Later, when the user32 garbage collector crashed, it crashed in exactly the same place as ARM, because the stack-based bookkeeping structure had been overwritten in the deferral.

On ARM, to further confirm that stack corruption was the issue, I inserted code in callbackasm1 to save the current g0 SP so that when unwindm restores the g0 SP, it will restore it to a value that is safely below the stack for EnumWindows. With this change, the crash went away because EnumWindow's stack was no longer being overwritten in the deferral. The test ran many times successfully.

Given these findings I have increased confidence that this is the issue.

@gopherbot
Copy link

@gopherbot gopherbot commented Dec 30, 2018

Change https://golang.org/cl/155923 mentions this issue: runtime: use EnumTimeFormatsEx instead of EnumWindows in callback tests

gopherbot pushed a commit that referenced this issue Dec 30, 2018
Use EnumTimeFormatsEx() to test panics across callback boundaries
instead of EnumWindows(). EnumWindows() is incompatible with Go's panic
unwinding mechanism. See the associated issue for more information.

Updates #26148

Change-Id: If1dd70885d9c418b980b6827942cb1fd16c73803
Reviewed-on: https://go-review.googlesource.com/c/155923
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
@jordanrh1
Copy link
Contributor Author

@jordanrh1 jordanrh1 commented Dec 31, 2018

Exciting stuff:
image

@petemoore
Copy link

@petemoore petemoore commented Jan 7, 2019

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

@jordanrh1
Copy link
Contributor Author

@jordanrh1 jordanrh1 commented Jan 7, 2019

@petemoore There is not.

@andybons andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019
@0xacf
Copy link

@0xacf 0xacf commented Feb 19, 2019

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
Copy link
Contributor Author

@jordanrh1 jordanrh1 commented Feb 19, 2019

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

@0xacf
Copy link

@0xacf 0xacf commented Feb 19, 2019

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
Copy link
Contributor Author

@jordanrh1 jordanrh1 commented Feb 20, 2019

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
Copy link

@0xacf 0xacf commented Feb 20, 2019

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
Copy link
Member

@alexbrainman alexbrainman commented Mar 24, 2019

@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
Copy link
Contributor

@bradfitz bradfitz commented Mar 24, 2019

@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
Copy link
Member

@alexbrainman alexbrainman commented Mar 24, 2019

@alexbrainman, the builders don't use git.

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

Alex

@jordanrh1
Copy link
Contributor Author

@jordanrh1 jordanrh1 commented Mar 25, 2019

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

@alexbrainman
Copy link
Member

@alexbrainman alexbrainman commented Mar 26, 2019

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
Copy link
Member

@bcmills bcmills commented May 20, 2019

@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
Copy link

@mirogl mirogl commented Sep 26, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.