Add support for windows/arm64

[qmuntal]

This PR adds support for debugging on windows/arm64. There are some tests failing, but with these changes I can use dlv to debug big codebases without problems.

I could reuse all work done to support arm64 on linux. The only difference is that windows use BRK 0xF000 as breakpoint instruction instead of just BRK.

On the windows syscall side, I've redefined CONTEXT so it matches Windows ARM64 expectations.

There are a couple of things that are still not supported:

• Core dumps
• Hardware breakpoints
• Some tests using runtime.Breakpoint() fail due to https://github.com/golang/go/issues/53837

Fixes #2129

[qmuntal]

I think we should wait to merge this until we have a version of Go that we can test it on. It doesn't have to be a released version, it could be go built at tip.

Go provides official windows/arm64 since go1.17, so this should be a blocker.

You say that some tests don't pass but made no changes to _test.go files, except core_test.go. Tests that don't pass should be skipped.

Will do that soon.

We would need to have some way to run CI on windows/arm64 otherwise it is going to break very soon

Agree. Could we at least merge the part of this PR that refactors windows to be more friendly to non-amd64 architectures? This will pave the path for when we have windows/arm64 CI and it will allow me, and other people wanting to debug arm64 using this branch, to patch arm64 support with minimal effort.

[aarzilli]

I think we should wait to merge this until we have a version of Go that we can test it on. It doesn't have to be a released version, it could be go built at tip.

Go provides official windows/arm64 since go1.17, so this should be a blocker.

I don't understand what you mean by this.

We would need to have some way to run CI on windows/arm64 otherwise it is going to break very soon

Agree. Could we at least merge the part of this PR that refactors windows to be more friendly to non-amd64 architectures? This will pave the path for when we have windows/arm64 CI and it will allow me, and other people wanting to debug arm64 using this branch, to patch arm64 support with minimal effort.

I think that's fine.

[qmuntal]

I think we should wait to merge this until we have a version of Go that we can test it on. It doesn't have to be a released version, it could be go built at tip.

Go provides official windows/arm64 since go1.17, so this should be a blocker.

I don't understand what you mean by this.

Then I don't understand your initial concern. Go already supports windows/arm64, so there is a version of Go that we can test it on. What's missing other than the CI?

[aarzilli]

Then I don't understand your initial concern. Go already supports windows/arm64, so there is a version of Go that we can test it on. What's missing other than the CI?

I was thinking about the problem with runtime.Breakpoint, I think we should wait until there's a version of go with a fixed runtime.Breakpoint, a large number of tests depends on runtime.Breakpoint being handled correctly.

[qmuntal]

@aarzilli I've rebased this PR and gated windows/arm64 behind the exp.winarm64 tag. What do you think?

I'm also struggling to run the test suite locally either on amd64 and arm64 because proc.FindFileLocation always returns ErrCouldNotFindLine. There seems to be a mishandling of the file name casing on windows.

[derekparker]

@aarzilli I've rebased this PR and gated windows/arm64 behind the exp.winarm64 tag. What do you think?

I'm also struggling to run the test suite locally either on amd64 and arm64 because proc.FindFileLocation always returns ErrCouldNotFindLine. There seems to be a mishandling of the file name casing on windows.

That's an odd one, our Windows builders seem to be running fine. Is there anything different about your test / development systems that could cause such an error? I don't have a Windows machine handy to test on right now.

[qmuntal]

That's an odd one, our Windows builders seem to be running fine. Is there anything different about your test / development systems that could cause such an error? I don't have a Windows machine handy to test on right now.

Found the culprit. I'm running the tests inside vscode, and for historical reasons they normalize the drive letter to lower-case. This shouldn't be a problem, because Windows file paths are case-insensitive, but proc.FindFileLocation is case sensitive, so it can't find the file even if it is there.

[derekparker]

That's an odd one, our Windows builders seem to be running fine. Is there anything different about your test / development systems that could cause such an error? I don't have a Windows machine handy to test on right now.

Found the culprit. I'm running the tests inside vscode, and for historical reasons they normalize the drive letter to lower-case. This shouldn't be a problem, because Windows file paths are case-insensitive, but proc.FindFileLocation is case sensitive, so it can't find the file even if it is there.

Ack, thanks for looking into that.

[qmuntal]

@aarzilli @derekparker I'm mostly done with this PR and all tests in pkg/proc are passing. Could you do one final review?

About the Windows ARM64 builder, anyone can register for the Azure Arm-based VMs public preview at https://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbRyMSy8VejZVEo6yZykiPSHpURFRIQVY1QTcyWTlJNURUS1pNTktOUTUxVi4u. See the announcement here: https://azure.microsoft.com/en-us/blog/now-in-preview-azure-virtual-machines-with-ampere-altra-armbased-processors/

It is not free of cost, I can't do anything here, but I can help setting up the testing environment once the VM is up and running.

[nathanhammond]

Thank you all for your work in getting this change landed! This will make a tremendous difference for our team and we're very appreciative. 🎉