macos-aarch64: segfault when running a CGo binary

[motiejus]

Steps to reproduce:

1. Take CoreFoundation.tbd from an existing MacOS M1 host

I use Ventura 13.2.1:

$ find ~/x/trimmed/ -type f
/home/motiejus/x/trimmed/MacOSX13.1.sdk/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation.tbd

2. Compile a Go binary (this file) on a Linux machine:

$ GOOS=darwin GOARCH=arm64 CGO_ENABLED=1 CC="/code/zig-linux-x86_64-0.11.0-dev.1975+e17998b39/zig cc -target aarch64-macos-none" go build -buildmode=pie -ldflags "-s -w -linkmode external -extldflags '--sysroot $HOME/x/trimmed/MacOSX13.1.sdk -F /System/Library/Frameworks' " .

3. Actual response

$ ./cgo
minpc= 0x102974960 min= 0x0 maxpc= 0x0 max= 0x0
fatal error: minpc or maxpc invalid
runtime: panic before malloc heap initialized

runtime stack:
zsh: segmentation fault  ./cgo

4. Expected response

$ ./cgo
hello, world

Metadata

Commands taken from @slimsag 's #11303 (comment)
go version 1.20.2 linux/amd64
zig 0.11.0-dev.1975+e17998b39

[kubkon]

BTW, did you check if it segfaults also when built natively on the target?

[motiejus]

BTW, did you check if it segfaults also when built natively on the target?

Please be more specific. No target, sysroot and F args to zig?

[kubkon]

Built directly on M1 rather than cross-compiled to it :-)

[motiejus]

Same:

motiejus@motiejus-K9KH5P7MP3 x % uname -a
Darwin motiejus-K9KH5P7MP3 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000 arm64
motiejus@motiejus-K9KH5P7MP3 x % find trimmed -type f                          
trimmed/MacOSX13.1.sdk/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation.tbd
motiejus@motiejus-K9KH5P7MP3 x % GOOS=darwin GOARCH=arm64 CGO_ENABLED=1 CC="$PWD/zig-macos-aarch64-0.11.0-dev.1975+e17998b39/zig cc -target aarch64-macos-none" go build -buildmode=pie -ldflags "-s -w -linkmode external -extldflags '--sysroot $HOME/x/trimmed/MacOSX13.1.sdk -F /System/Library/Frameworks' " .

motiejus@motiejus-K9KH5P7MP3 x % ./x
minpc= 0x100774960 min= 0x0 maxpc= 0x0 max= 0x0
fatal error: minpc or maxpc invalid
runtime: panic before malloc heap initialized

runtime stack:
zsh: segmentation fault  ./x
motiejus@motiejus-K9KH5P7MP3 x % 

[motiejus]

Same story in native compilation mode:

motiejus@motiejus-K9KH5P7MP3 x % CGO_ENABLED=1 CC="$PWD/zig-macos-aarch64-0.11.0-dev.1975+e17998b39/zig cc" go build -buildmode=pie -ldflags "-s -w -linkmode external" .

motiejus@motiejus-K9KH5P7MP3 x % ./x                                                                                                                                     
minpc= 0x100648960 min= 0x0 maxpc= 0x0 max= 0x0
fatal error: minpc or maxpc invalid
runtime: panic before malloc heap initialized

runtime stack:
zsh: segmentation fault  ./x
motiejus@motiejus-K9KH5P7MP3 x % 

[kubkon]

Yeah, I already reproed it locally, but thanks for double checking. I can report that the issue so far doesn't surface on Intel Macs, only on Apple Silicon. This issue also uncovered bugs in DWARF parser in the MachO linker so I am fixing both at once.

[kubkon]

@motiejus fix incoming in #15041 As an added bonus I got to learn a bit more how Go's linker actually works.

[motiejus]

(lldb) run
Process 13613 launched: '/Users/motiejus/x/x' (arm64)
Process 13613 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x30)
    frame #0: 0x000000010002ed28 x`runtime.schedinit + 264
x`runtime.schedinit:
->  0x10002ed28 <+264>: ldr    x1, [x0, #0x30]
    0x10002ed2c <+268>: ldrsb  x27, [x1]
    0x10002ed30 <+272>: orr    x2, xzr, #0x3
    0x10002ed34 <+276>: str    w2, [sp, #0x8]
Target 0: (x) stopped.
(lldb) 

x.pptx

[motiejus]

Myself and @kubkon spent some time looking at this in real time. Observations from Jakub:

• addendum before a branch seems really weird.
• looking at the relocation file for go.o it looked like ADDENDs were misplaced: there were some before the branches. Felt like a bug in Go.
• Seems pretty similar to cmd/link: Incorrect symbol linked in darwin/arm64 golang/go#58935

Turns out golang/go#58935 is not part of Go 1.20.2 (which we tested). The current Zig master interacts well with the current Go master (both unreleased, ha ha). So we're good.