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

[andrewrk]

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]

Duplicate of #43078
oops read the issue too quickly

[AlexRouSg]

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

[andrewrk]

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?

[AlexRouSg]

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

[andrewrk]

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

[dominikh]

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

[mdempsky]

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.

[Sobeston]

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.

[Sobeston]

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

[LaPingvino]

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