debug/dwarf: cgo produces malformed DWARF data
Closed this issue · 15 comments
What version of Go are you using (go version)?
$ go version go version go1.12.6 darwin/amd64
Does this issue reproduce with the latest release?
Yes, including master.
What operating system and processor architecture are you using (go env)?
macOS 10.15 beta 2
go env Output
$ go env GOARCH="amd64" GOBIN="" GOCACHE="/Users/mistydemeo/Library/Caches/go-build" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOOS="darwin" GOPATH="/Users/mistydemeo/go" GOPROXY="" GORACE="" GOROOT="/usr/local/Cellar/go/1.12.6/libexec" GOTMPDIR="" GOTOOLDIR="/usr/local/Cellar/go/1.12.6/libexec/pkg/tool/darwin_amd64" GCCGO="gccgo" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/Users/mistydemeo/oss/go/src/go.mod" 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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/y2/qxl_xqt53vb2f5yrkmtdkyxc0000gn/T/go-build736553091=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
Build a Go binary with cgo usage, for example https://github.com/sstephenson/launch_socket_server
What did you expect to see?
Binary is built and works.
What did you see instead?
Binary receives a SIGABRT with the following error:
dyld: malformed mach-o image: segment __DWARF has vmsize < filesize
fish: 'launch_socket_server' terminated by signal SIGABRT (Abort)
Examining some binaries produced by Go, it appears this bug predates macOS 10.15; however, the macOS 10.15 SDK is pickier about it, and any malformed binaries built against it will fail to execute with this error.
I've tested using the latest master to see if any of the commits reference #31459 affect it, but this behaviour still occurs.
Thank you for this report @mistydemeo!
I shall page some experts @ianlancetaylor @heschik @dr2chase
That definitely looks related.
Well, I am a little out of my depth here (not a MachO expert) but looking at the dyld source here around line 287 it might be possible to work around this by setting the initial protection to zero.
I don't have any viable way to test the fix, though -- the strict checking in question is hardwired based on the OS version it looks like.
@mistydemeo if I send a CL would you be able to test it (e.g. apply patch to Go source, rebuild, etc)?
@thanm Yes, absolutely. I can test. I've been testing a few tweaks locally so far, glad to test anything you send me too!
Change https://golang.org/cl/182958 mentions this issue: cmd/link: macos: set initial protection of 0 for __DWARF segment
OK, thanks. I sent a CL -- if you can patch that in and see if it helps, I'd be grateful.
Confirmed that has fixed the issue. After building Go at this branch, I tried rebuilding launch_socket_server and another affected project and both are now accepted by dyld.
Cool, glad to hear it. I'll see about getting it reviewed and checked in. Thanks for your help.
Thanks! Can you make sure this gets backported to all maintenance branches, please? I can also open backport requests if you'd like.
Yes, if you can open requests I can follow up.
@gopherbot please consider this for backport, it's a regression
Backport issue(s) opened: #32696 (for 1.11), #32697 (for 1.12).
Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.
Change https://golang.org/cl/183237 mentions this issue: cmd/link: revise previous __DWARF segment protection fix