search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
123.09k stars 17.55k forks source link

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

Open TopperDEL opened 3 years ago

TopperDEL commented 3 years ago

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 commented 3 years ago

CC @zx2c4

TopperDEL commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Ah, thanks.

TopperDEL commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

gopherbot commented 3 years ago

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

gopherbot commented 3 years ago

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

gopherbot commented 3 years ago

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

gopherbot commented 3 years ago

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

gopherbot commented 3 years ago

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

TopperDEL commented 3 years ago

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 commented 3 years ago

Any news on this one? :)

TopperDEL commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

We were able to track down what was causing this issue, @TopperDEL has opened another issue as to how we fix it here: https://github.com/golang/go/issues/50877

gopherbot commented 2 years ago

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

gopherbot commented 1 year ago

Change https://go.dev/cl/463117 mentions this issue: runtime: run TestVectoredHandlerDontCrashOnLibrary on 386 and arm64

qmuntal commented 8 months ago

Note that windows/arm64 already supports -buildmode=c-shared. I'm removing the arch-arm64 label.