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/cgo: rt0_go failure on Windows when using zig cc #43886

Open
andrewrk opened this issue Jan 24, 2021 · 21 comments
Open

cmd/cgo: rt0_go failure on Windows when using zig cc #43886

andrewrk opened this issue Jan 24, 2021 · 21 comments

Comments

@andrewrk
Copy link

@andrewrk andrewrk commented Jan 24, 2021

Hello, any Go developers interested in working with Zig developers on this use case?

Upstream issue: ziglang/zig#7874
Tested with go 1.15.5.

main.go

package main

//int Add(int a, int b){
//    return a+b;
//}
import "C"
import "fmt"

func main() {
	a := C.int(10)
	b := C.int(20)
	c := C.Add(a, b)
	fmt.Println(c) // 30
}

CGO_ENABLED=1 GOOS=windows GOARCH=amd64 CC="zcc" CXX="zc++" go build main.go

zcc

#!/bin/sh
zig cc -target x86_64-windows-gnu $@

zc++

#!/bin/sh
zig c++ -target x86_64-windows-gnu $@

output:

# command-line-arguments
warning: unsupported linker arg: --compress-debug-sections=zlib-gnu

It produces main.exe but when run it segfaults in runtime.rt0_go() (called from main()). Expected output is to print "30" to the console when run in cmd.exe.

Happy to chat on IRC or Discord if anyone has some ideas to try.

@AlexRouSg

This comment has been hidden.

@AlexRouSg
Copy link
Contributor

@AlexRouSg AlexRouSg commented Jan 24, 2021

@andrewrk does anything change if you add the -buildmode=exe flag to go build?

Loading

@andrewrk
Copy link
Author

@andrewrk andrewrk commented Jan 25, 2021

no- still get a segfault at:

0x000000014013b53c runtime.rt0_go+0x5c in main: movb	$0x1,0xfffffffffffccee7(%rip)

was go/cgo expecting the linker to do something that perhaps didn't get done here?

it looks like one of these:

go/src/runtime/asm_amd64.s

Lines 123 to 124 in d047c91

MOVB $1, runtime·isIntel(SB)
MOVB $1, runtime·lfenceBeforeRdtsc(SB)

looks like writing to this memory is segfaulting:

go/src/runtime/runtime2.go

Lines 1095 to 1096 in d047c91

isIntel bool
lfenceBeforeRdtsc bool

so my question would be: in what way does go emit an object for runtime2.go, and how is the address for those variables computed in the object for asm_amd64.s?

Loading

@AlexRouSg
Copy link
Contributor

@AlexRouSg AlexRouSg commented Jan 25, 2021

@ianlancetaylor would be the best person to talk to about this but I'm not too sure if this should be discussed here cause the issue tracker is normally for bugs and zig isn't exactly the intended/expected compiler/linker.

Loading

@andrewrk
Copy link
Author

@andrewrk andrewrk commented Jan 25, 2021

hmm I think this may be an issue with cgo though; is that in scope for this issue tracker?

Loading

@dominikh
Copy link
Member

@dominikh dominikh commented Jan 25, 2021

Let's keep this issue open until we know if this is a bug in zig or in Go.

Loading

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Jan 25, 2021

I don't have any familiarity with using zig. Can you give instructions on how to easily reproduce this issue from a clean Linux install?

A docker image would be ideal.

Loading

@mdempsky mdempsky changed the title use case: using zig cc to cross compile a cgo program for windows cmd/cgo: rt0_go failure on Windows when using zig cc Jan 25, 2021
@mdempsky mdempsky added this to the Unplanned milestone Jan 25, 2021
@Sobeston
Copy link

@Sobeston Sobeston commented Jan 25, 2021

Reproduced with go 1.15.6 linux/amd64, full output here: https://pastebin.com/BmVtawS1

@mdempsky Assuming you have go installed already, all you should need is a master copy of zig. For you this probably means getting a binary from https://ziglang.org/download/ and adding it to your path (shouldn't need any more setup than this). Personally I get my version from the "zig-git" aur package.

Loading

@Sobeston
Copy link

@Sobeston Sobeston commented Jan 25, 2021

Also tested on go 1.15.7 linux/amd64; same problem https://pastebin.com/wHw49gWf.

Loading

@LaPingvino
Copy link

@LaPingvino LaPingvino commented Feb 15, 2021

I thought maybe filtering out the zlib-gnu invocation from Go might fix it, which I did with using this for the shell wrapper:

#!/bin/bash
INVOKE=${@/-Wl,--compress-debug-sections=zlib-gnu/}
echo $INVOKE
zig cc -target x86_64-windows-gnu $INVOKE

(set invoke to $@ to see the full invocation that CGo does)

and that does seem to solve the error, but I'm not sure if the resulting binary is as expected, adding it here, cannot test because compiled on Linux ARM64: zigandgotest.zip

Loading

@LaPingvino
Copy link

@LaPingvino LaPingvino commented Feb 15, 2021

Update: found a Windows machine to test on, running that binary doesn't give any errors but doesn't produce the desired result (fyne hello world) either.

Loading

@zx2c4
Copy link
Contributor

@zx2c4 zx2c4 commented Feb 15, 2021

Loading

@LaPingvino
Copy link

@LaPingvino LaPingvino commented Feb 18, 2021

Context to @zx2c4's reference (correct me if I'm wrong...): LLVM builds seem to have been broken for Windows with CGo before, but it wasn't really an issue until trying to get ARM64 on Windows to work. Fixes are applied now to get Windows/ARM64 working, and those should fix Windows builds across the board.

Loading

@zx2c4
Copy link
Contributor

@zx2c4 zx2c4 commented Feb 18, 2021

Those fixes haven't been applied yet. I'm hoping @rsc will submit them with the rest of the windows/arm64 series in the near future.

Loading

@LaPingvino
Copy link

@LaPingvino LaPingvino commented Feb 18, 2021

Yeah, the patch you refer to is still stuck in trybot-hell atm xD. If you have a branch with these fixes applied I would love to test that for the purpose of this bug.

Loading

@zx2c4
Copy link
Contributor

@zx2c4 zx2c4 commented Feb 18, 2021

Here's what I'm building with at the moment: https://download.wireguard.com/windows-toolchain/distfiles/go1.16-2021-02-18.zip It's 1.16 plus a bunch of extras. Cgo works with Clang but I haven't tried zig's wrapper yet. Let me know how it goes.

Loading

@LaPingvino
Copy link

@LaPingvino LaPingvino commented Feb 18, 2021

$ CC="zcc" CGO_ENABLED=1 GOOS=windows GOARCH=amd64 go build
# fyne-hello
warning: unsupported linker arg: --compress-debug-sections=zlib-gnu

zigandgotest.zip

Loading

@LaPingvino
Copy link

@LaPingvino LaPingvino commented Feb 18, 2021

Tested with wine on my amd64 system: works. Might need to file the unsupported linker arg thing separately. So it's very likely that this bug will be fixed when the Windows/ARM64 patches are in.

Loading

@LaPingvino
Copy link

@LaPingvino LaPingvino commented Feb 19, 2021

The argument order patch should fix the zlib-gnu warning, @zx2c4 said to check out that patch and with a bit of luck I will be able to test that too.

Loading

@LaPingvino
Copy link

@LaPingvino LaPingvino commented Feb 19, 2021

@zx2c4 as we found that your version works, maybe link/mention the relevant bugs here so Github can help us keep track if we can close this bug?

Loading

@LaPingvino
Copy link

@LaPingvino LaPingvino commented Mar 2, 2021

The argument order patch should fix the zlib-gnu warning, @zx2c4 said to check out that patch and with a bit of luck I will be able to test that too.

Doesn't seem to be an order patch yet? Current master seems to fix issue otherwise 👍 (while still needing the workaround)

Loading

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
7 participants