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

cmd/link: -buildmode=c-shared not supported on windows/arm #43800

Open
TopperDEL opened this issue Jan 20, 2021 · 24 comments · May be fixed by #50889
Open

cmd/link: -buildmode=c-shared not supported on windows/arm #43800

TopperDEL opened this issue Jan 20, 2021 · 24 comments · May be fixed by #50889
Labels
arch-arm arch-arm64 FeatureRequest NeedsInvestigation OS-Windows
Milestone

Comments

@TopperDEL
Copy link

@TopperDEL TopperDEL commented Jan 20, 2021

What version of Go are you using (go version)?

$ go version 1.15.6

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/vsts/.cache/go-build"
GOENV="/home/vsts/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/vsts/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/vsts/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/hostedtoolcache/go/1.15.6/x64"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/hostedtoolcache/go/1.15.6/x64/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build442356246=/tmp/go-build -gno-record-gcc-switches"

What 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"

@bcmills
Copy link
Member

@bcmills bcmills commented Jan 20, 2021

CC @zx2c4

@dmitshur dmitshur added this to the Backlog milestone Jan 20, 2021
@dmitshur dmitshur added the NeedsInvestigation label Jan 20, 2021
@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Feb 4, 2021

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!

@thanm
Copy link
Contributor

@thanm thanm commented Feb 4, 2021

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.

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 4, 2021

I think the main stumbling block is that we haven't had an owner for the port, nor have we a builder.

We do have a builder now, at least! (A “reverse” builder run by @zx2c4.)
https://github.com/golang/build/blob/6f0aa4e1ac923ee1f8249641d38ecb96db02a1e8/dashboard/builders.go#L2250-L2256

@thanm
Copy link
Contributor

@thanm thanm commented Feb 4, 2021

Ah, thanks.

@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Feb 4, 2021

I'm not that deep into Go and how builders work and help here - what needs to happen then to bring this further?
Thank you all for your help and quick response!

@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Feb 11, 2021

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!

@cherrymui
Copy link
Member

@cherrymui cherrymui commented Feb 11, 2021

windows/arm port doesn't support cgo yet. I think we need to support cgo before adding support of c-shared build mode. Thanks.

@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Feb 12, 2021

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

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 13, 2021

Change https://golang.org/cl/291630 mentions this issue: cmd/link: set SizeOfRawData filed in COFF files for .bss section

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 13, 2021

Change https://golang.org/cl/291630 mentions this issue: cmd/link: set SizeOfRawData field in COFF files for .bss section

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 14, 2021

Change https://golang.org/cl/291632 mentions this issue: cmd/link: do not pass -Bsymbolic for PE DLLs

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 14, 2021

Change https://golang.org/cl/291633 mentions this issue: cmd/link: set .ctors COFF section to writable and aligned to 8 bytes

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 14, 2021

Change https://golang.org/cl/291633 mentions this issue: cmd/link: set .ctors COFF section to writable and aligned

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 14, 2021

Change https://golang.org/cl/291635 mentions this issue: runtime/cgo: implement for windows/arm and windows/arm64

gopherbot pushed a commit that referenced this issue Feb 23, 2021
… .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>
gopherbot pushed a commit that referenced this issue Feb 23, 2021
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>
gopherbot pushed a commit that referenced this issue Feb 23, 2021
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>
@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Mar 18, 2021

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!

@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Apr 29, 2021

Any news on this one? :)

@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Jun 11, 2021

According to the release notes of Go 1.17 beta1, this should work now - am I right?
https://tip.golang.org/doc/go1.17#ports

"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:

export CC="arm-none-eabi-gcc"     
export CXX="arm-none-eabi-g++"     
export GOOS="windows"     
export GOARCH="arm64"     
export GOARM=7     
export CGO_ENABLED="1"     
/home/vsts/go/bin/go1.17beta1 build -ldflags="-s -w" -o storj_uplink.dll -buildmode c-shared

I get this:
-buildmode=c-shared not supported on windows/arm64

Is there still something missing?

@zx2c4
Copy link
Contributor

@zx2c4 zx2c4 commented Jun 11, 2021

This github issue is for windows/arm, not for windows/arm64, and is therefore not related to the contents of your message.

What you're looking for is https://go-review.googlesource.com/c/go/+/326310/ which is a work in progress.

@zx2c4
Copy link
Contributor

@zx2c4 zx2c4 commented Jun 11, 2021

@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?

@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Jun 11, 2021

This github issue is for windows/arm, not for windows/arm64, and is therefore not related to the contents of your message.

What you're looking for is https://go-review.googlesource.com/c/go/+/326310/ which is a work in progress.

Ah, missed that - thank you.

@TopperDEL
Copy link
Author

@TopperDEL TopperDEL commented Jan 27, 2022

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.

0x00007FFAC6ADC858 - storj_uplink.dll!badsignal2()
0x00007FFAC6ADC824 - storj_uplink.dll!badsignal2()
0x00007FFAC6ADC5A4 - storj_uplink.dll!_rt0_arm64_windows_lib_go�()
0x00007FFAEF3AFBB8 - ntdll.dll!RtlpCallVectoredHandlers()
ntdll.dll!RtlpCallVectoredHandlers()
ntdll.dll!RtlDispatchException()
ntdll.dll!KiUserExceptionDispatch�()
KernelBase.dll!RaiseException�()
ucrtbase.dll!00007ffaee35156c()
CoreMessaging.dll!Microsoft::CoreUI::Messaging::MessagingValidationException::ThrowVirtual$(void)
CoreMessaging.dll!System::Exception::Throw$()
CoreMessaging.dll!Microsoft::CoreUI::Registrar::RegistrarClient::FindEndpointAPIWorker()
CoreMessaging.dll!Microsoft::CoreUI::Registrar::RegistrarClient::InterfaceImplementation$::_Microsoft_CoreUI_IExportMessageRegistrar::Dispatcher::FindEndpoint(class System::Object *,class System::String *,enum Microsoft::CoreUI::ExternalRegistrarScope)
CoreMessaging.dll!Microsoft::CoreUI::IExportMessageRegistrar::ExportAdapter$::FindEndpoint()
InputHost.dll!CursorClient::Initialize(void)
InputHost.dll!CursorClient::Create(struct ICursorClient * *)
MinUser.dll!<lambda_5e81620151fbc846d7720434fb87b013>::<lambda_invoker_cdecl>()
KernelBase.dll!InitOnceExecuteOnceCallback�()
ntdll.dll!RtlRunOnceExecuteOnce()
KernelBase.dll!InitOnceExecuteOnce�()
MinUser.dll!CursorClientExists(void)
MinUser.dll!Core::CursorInfo::_SetCursor(unsigned __int64)
MinUser.dll!Core::Api::SetCursor(enum Core::CursorHandle)
MinUser.dll!minSetCursor�()
Windows.UI.dll!Windows::UI::Core::WindowServer::ReloadCursorOnEnter()
Windows.UI.dll!Windows::UI::Core::WindowServer::CreateDefaultCursor()
Windows.UI.dll!Windows::UI::Core::WindowServer::RuntimeClassInitialize()
Windows.UI.dll!PrivateCreateCoreWindow()
CoreUIComponents.dll!CreateCoreWindow2()
CoreUIComponents.dll!CoreWindowFactoryProxy::CreateCoreWindow(struct HSTRING__ *,struct Windows::UI::Core::ICoreWindow * *)
twinapi.appcore.dll!Windows::ApplicationModel::Core::CoreApplicationView::SetWindowAndGetDispatcher()
rpcrt4.dll!Invoke�()
rpcrt4.dll!InvokeHelper()
rpcrt4.dll!Ndr64StubWorker(void *,void *,struct _RPC_MESSAGE *,struct _MIDL_SERVER_INFO_ *,long (*const *)(void),struct _MIDL_SYNTAX_INFO *,unsigned long *)
rpcrt4.dll!NdrStubCall3()
combase.dll!CStdStubBuffer_Invoke(IRpcStubBuffer * This=0x000001987d616610, tagRPCOLEMESSAGE * prpcmsg=0x000001983a3e63b0, IRpcChannelBuffer * pRpcChannelBuffer=0x000001983a3d9170) Zeile 1480
rpcrt4.dll!CStdStubBuffer_Invoke()
[Inlineframe] combase.dll!InvokeStubWithExceptionPolicyAndTracing::__l6::<lambda_c9f3956a20c9da92a64affc24fdd69ec>::operator()() Zeile 1279
combase.dll!ObjectMethodExceptionHandlingAction<<lambda_c9f3956a20c9da92a64affc24fdd69ec>>(InvokeStubWithExceptionPolicyAndTracing::__l6::<lambda_c9f3956a20c9da92a64affc24fdd69ec> action, ObjectMethodExceptionHandlingInfo * pExceptionHandlingInfo=0x0000004549ffeb00, ExceptionHandlingResult * pExceptionHandlingResult=0x0000004549ffea88, void *) Zeile 94
[Inlineframe] combase.dll!InvokeStubWithExceptionPolicyAndTracing(IRpcStubBuffer * pMsg=0x000001983a3e63b0, tagRPCOLEMESSAGE *) Zeile 1277
combase.dll!DefaultStubInvoke(bool bIsAsyncBeginMethod=false, IServerCall * pServerCall=0x000001983a3cb368, IRpcChannelBuffer * pChannel=0x000001983a3d9170, IRpcStubBuffer * pStub=0x000001987d616610, unsigned long * pdwFault=0x0000004549fff0e0) Zeile 1346
[Inlineframe] combase.dll!SyncStubCall::Invoke(IServerCall *) Zeile 1403
[Inlineframe] combase.dll!SyncServerCall::StubInvoke(IRpcChannelBuffer *) Zeile 780
[Inlineframe] combase.dll!StubInvoke(tagRPCOLEMESSAGE * pMsg=0x000001983a3e63b0, CStdIdentity * pStdID=0x000001987d619560, IRpcStubBuffer *) Zeile 1628
combase.dll!ServerCall::ContextInvoke(tagRPCOLEMESSAGE * pMessage=0x000001983a3e63b0, IRpcStubBuffer * pStub=0x000001987d616610, CServerChannel * pChannel=0x000001983a3d9170, tagIPIDEntry * pIPIDEntry=0x000001983a28ee28, unsigned long * pdwFault=0x0000004549fff0e0) Zeile 1423
[Inlineframe] combase.dll!CServerChannel::ContextInvoke(tagRPCOLEMESSAGE *) Zeile 1332
[Inlineframe] combase.dll!DefaultInvokeInApartment(tagRPCOLEMESSAGE *) Zeile 3297
combase.dll!ASTAInvokeInApartment(tagRPCOLEMESSAGE * pMsg=0x000001983a3e63b0, unsigned long dwCallCat, bool bIsTouchedASTACall, IRpcStubBuffer * pStub=0x000001987d616610, CServerChannel * pChnl=0x000001983a3d9170, tagIPIDEntry * pIPIDEntry=0x000001983a28ee28, unsigned long * pdwFault=0x0000004549fff0e0) Zeile 471
[Inlineframe] combase.dll!AppInvoke(ServerCall * pStub=0x000001987d616610, CServerChannel *) Zeile 1122
combase.dll!ComInvokeWithLockAndIPID(ServerCall * pServerCall=0x000001983a3cb340, tagIPIDEntry * pIPIDEntry=0x000001983a28ee28, bool * pbCallerResponsibleForRequestMessageCleanup=0x0000004549fff6c0) Zeile 2225
combase.dll!ComInvoke(ServerCall * pServerCall=0x000001983a3cb340, bool * pbCallerResponsibleForRequestMessageCleanup=0x0000004549fff6c0) Zeile 1700
combase.dll!ThreadDispatch(ServerCall * pServerCall=0x000001983a3cb340) Zeile 417
combase.dll!ModernSTAState::HandleMessage(IMessageParam * pParam=0x000001983a3cb350) Zeile 465
combase.dll!ModernSTAWaitContext::Wait(unsigned int cHandlesOuter=0x00000002, void * const * pHandlesOuter, unsigned long dwTimeoutOuter=0xffffffff, ModernSTAWaitContext::ProcessEventsMsgWaitParams * pProcessEventsMsgWaitParams=0x0000004549fffb08, unsigned long * pdwLastError=0x0000004549fffb00) Zeile 1458
combase.dll!CoMsgWaitInProcessEvents(CO_PROCESS_EVENTS_CONTEXT * pContext=0x0000004549fffb58, unsigned long nCount=0x00000002, void * const * pHandles=0x0000004549fffb48, unsigned long dwMilliseconds=0xffffffff, unsigned long dwWakeMask, unsigned long dwFlags) Zeile 2554
Windows.UI.dll!Windows::UI::Core::CDispatcher::WaitAndProcessMessagesInternal()
Windows.UI.dll!Windows::UI::Core::CDispatcher::WaitAndProcessMessages()
twinapi.appcore.dll!<Lambdafunktion>(void)()
SHCore.dll!_WrapperThreadProc()
ntdll.dll!RtlUserThreadStart()

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.
Any help greatly appreciated!!

@marler8997
Copy link

@marler8997 marler8997 commented Jan 28, 2022

We were able to track down what was causing this issue, @TopperDEL has opened another issue as to how we fix it here: #50877

marler8997 added a commit to marler8997/go that referenced this issue Jan 28, 2022
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.
@gopherbot
Copy link

@gopherbot gopherbot commented Jan 28, 2022

Change https://golang.org/cl/381775 mentions this issue: runtime: fix sigtramp on windows arm64 platform

marler8997 added a commit to marler8997/go that referenced this issue Jan 28, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-arm arch-arm64 FeatureRequest NeedsInvestigation OS-Windows
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants