cmd/link: -buildmode=c-shared not supported on windows/arm #43800
Comments
seankhliao
added
arch-arm
|
CC @zx2c4 |
dmitshur
added
the
NeedsInvestigation
|
Is there anything I could do? Might it already work just by adjusting the parameter check and let that combination "go through"? If not: is there any ETA for this? I do not want to make pressure - it's just quite necessary for an app I'm currently building and it would at least be helpful to get a feeling about the complexity, if it should be possible or not and when it might be realistic that the feature will make it into Go. This would bring Go to devices like the HoloLens 2 or a Surface X. I can't imagine that I'm the only one needing this. :) Thank you! |
|
I'm not aware of any specific issues blocking "-buildmode=c-shared" on windows/arm, maybe @cherrymui knows more. I think the main stumbling block is that we haven't had an owner for the port, nor have we a builder. You could certainly try commenting out the guard in the linker and see how things go. |
We do have a builder now, at least! (A “reverse” builder run by @zx2c4.) |
|
Ah, thanks. |
|
I'm not that deep into Go and how builders work and help here - what needs to happen then to bring this further? |
|
Sorry if I push here - what needs to be done to get further? There seems to be a builder available. Can someone bringt this topic further? Thank you in advance! |
|
windows/arm port doesn't support cgo yet. I think we need to support cgo before adding support of c-shared build mode. Thanks. |
|
Thanks @cherrymui for the reply. I'm sorry for asking again and again but what/who could do this? I need windows/arm64 with cgo very soon so if there is anything someone could do to bring this further, I would be very happy and thankful. :) |
|
Change https://golang.org/cl/291630 mentions this issue: |
|
Change https://golang.org/cl/291630 mentions this issue: |
|
Change https://golang.org/cl/291632 mentions this issue: |
|
Change https://golang.org/cl/291633 mentions this issue: |
|
Change https://golang.org/cl/291633 mentions this issue: |
|
Change https://golang.org/cl/291635 mentions this issue: |
… .bss section GCC and Clang both set the SizeOfRawData field rather than the VirtualSize field for communicating the size of the .bss section. As a consequence, LLD does not look at VirtualSize and collapses the .bss section into whatever is around it, resulting in runtime crashes. This commit changes the logic so that if the requested "file size" is 0, then the SizeOfRawData field is set rather than the VirtualSize field as the sole length marker. Fixes #44250. Fixes #39326. Updates #38755. Updates #36439. Updates #43800. Change-Id: Ied89ddaa0a717fed840238244c6e4848845aeeb6 Reviewed-on: https://go-review.googlesource.com/c/go/+/291630 Trust: Jason A. Donenfeld <Jason@zx2c4.com> Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
This is only a valid option on ELF. Binutils accepts it, but LLVM rejects it, so for Windows, it's best to just omit it. Updates #44250. Updates #39326. Updates #38755. Updates #36439. Updates #43800. Change-Id: Iffd2345d757f23dd737e63bd464cd412527077c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/291632 Trust: Jason A. Donenfeld <Jason@zx2c4.com> Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Without setting these flags, LLVM's LLD ignores the .ctors section when merging objects. Updates #44250. Updates #39326. Updates #38755. Updates #36439. Updates #43800. Change-Id: I8766104508f7acd832088a590ee7d68afa0d6065 Reviewed-on: https://go-review.googlesource.com/c/go/+/291633 Trust: Jason A. Donenfeld <Jason@zx2c4.com> Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
|
Can someone provide me with an update on this issue? I do not understand all the implications here and where to get the status. But I need this to be fixed/enhanced so I appreciate every feedback I get. Thank you very much! |
|
Any news on this one? :) |
|
According to the release notes of Go 1.17 beta1, this should work now - am I right? "Go 1.17 adds support of 64-bit ARM architecture on Windows (the windows/arm64 port). This port supports cgo." But if It try this: I get this: Is there still something missing? |
|
This github issue is for What you're looking for is https://go-review.googlesource.com/c/go/+/326310/ which is a work in progress. |
|
@rsc - do you intend to work on windows/arm cgo support for 1.18? If so, great. If not, could you let me know so I can potentially allocate resources to it? |
Ah, missed that - thank you. |
|
I'm still trying to make my go-based Hololens2/ARM64-app working, where I originally created this issue. Basically it is working - I can somehow call my code. But as this is all intended to run within a UWP-app (Universal Windows Platform) from Microsoft, it crashed with a weird stack trace. I'm not sure, if this is related to the ARM/ARM64-support and if there might be an initialization-issue left. But maybe someone knows what this might be. I got this huge stack trace once UWP initializes. My guess is (but I'm a complete noob in this field) that the UWP-runtime/sandbox throws an error and that "bubbles up" to the go-runtime. If anyone could tell me what the third and fourth line might mean or why it could be that Windows.UI-Exceptions lead to badsignal in go, that would be great. I have a test-repo available for this here and an open StackOverflow-Question there. But basically I need to know if especially on ARM64 there might be something that might interfere with the UWP-runtime. |
|
We were able to track down what was causing this issue, @TopperDEL has opened another issue as to how we fix it here: #50877 |
Fixes: golang#43800 This fixes the sigtramp handler on Windows. Note that unlike linuxy platforms, sigtramp is not actually a "trampoline" function. Instead, The code needed to handle interrupts in userspace is provided by Windows by some other means. On Windows the mechanism they provide is called "Vectored Exception Handling". Windows provides the AddVectoredExceptionHandler to register a callback function whenever an interrupt occurs which could be triggered by a signal/exception/etc. Windows supports multiple handlers and will call them one after the other stopping or continuing based on the return value as it goes along. In the case of go, it appears that sigtramp doesn't need to handle exceptions on threads that it hasn't initialized with the runtime. So in the case of windows, returning 0 from the exception handler will cause it to move on to the next exception handler. This is the change I've made here. This change has been built and verified to fix golang#43800 on a hololens arm64 windows device. Note that this also appears to be a problem for arm (sys_windows_arm.s). I'm currently not set up to test this on arm so maybe this could be fixed in a follow up change.
|
Change https://golang.org/cl/381775 mentions this issue: |
This fixes the sigtramp handler on Windows. Note that unlike linuxy platforms, sigtramp is not actually a "trampoline" function. Instead, The code needed to handle interrupts in userspace is provided by Windows by some other means. On Windows the mechanism they provide is called "Vectored Exception Handling". Windows provides the AddVectoredExceptionHandler to register a callback function whenever an interrupt occurs which could be triggered by a signal/exception/etc. Windows supports multiple handlers and will call them one after the other stopping or continuing based on the return value as it goes along. In the case of go, it appears that sigtramp doesn't need to handle exceptions on threads that it hasn't initialized with the runtime. So in the case of windows, returning 0 from the exception handler will cause it to move on to the next exception handler. This is the change I've made here. This change has been built and verified to fix golang#43800 on a hololens arm64 windows device. Note that this also appears to be a problem for arm (sys_windows_arm.s). I'm currently not set up to test this on arm so maybe this could be fixed in a follow up change. Fixes golang#43800
gopherbot
added
the
compiler/runtime
|
Change https://go.dev/cl/463117 mentions this issue: |
This CL updates TestVectoredHandlerDontCrashOnLibrary so it can run on windows/386 and windows/arm64. It still can't run on windows/arm as it does not support c-shared buildmode (see #43800). Change-Id: Id1577687e165e77d27633c632634ecf86e6e9d6f Reviewed-on: https://go-review.googlesource.com/c/go/+/463117 Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
|
Note that windows/arm64 already supports |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
I try to cross-compile a Go-library for windows/arm and windows/arm64 to P/Invoke it from .Net. Although Go states to support "windows/arm" as a build target this is not true for buildmode=c-shared.
What did you expect to see?
windows/arm being supported.
What did you see instead?
"-buildmode c-shared not supported for windows/arm"
The text was updated successfully, but these errors were encountered: