cmd/link: Xcode 8.3 dsymutil rejects our binaries

[rsc]

In src/runtime/testdata/testprogcgo, running the final parts of a link by hand:

$ ls -l testprogcgo
-rwxr-xr-x  1 rsc  eng  2008504 Mar 29 14:35 testprogcgo
$ dsymutil -f testprogcgo -o testprogcgo.dw
warning: (x86_64) /tmp/go.o unable to open object file: Invalid data was encountered while parsing the file
$ echo $?
0
$

The resulting binary is malformed.

This is the root cause of #19734, but we'll treat that issue as fixed by the workaround of not trusting dsymutil's exit status when it prints "warnings" (for backport to Go 1.8).

This issue is to fix our object files to be compatible with dsymutil, for Go 1.9.

[gopherbot]

CL https://golang.org/cl/38747 mentions this issue.

[gregory-m]

I bisected https://github.com/llvm-mirror/llvm
(I definitely don't miss c++ compile times)

The problem with go compiler starts at llvm-mirror/llvm@9a41e59

[gregory-m]

Also please notice apple's and llvm's dsymutil is different binaries.

Apple dsymutil default output is:

error: No input files.

llvml dsymutil default output is:

dsymutil: Not enough positional command line arguments specified!
Must specify at least 1 positional argument: See: ./bin/dsymutil - help

I don't know how Apple use llvm in Xcode. But I can compile go binaries with cgo on mac os 10.12.3 using llvm's dsymutil before 9a41e59, and can't compile with llvm's dsymutil after this change.

[rsc]

@gregory-m, thanks for tracking that down. I've got a fix pending and it is definitely related to the alignment of the DWARF segment having changed.

[gopherbot]

CL https://golang.org/cl/38855 mentions this issue.

[tamird]

@rsc could this be backported for 1.8.1?

[dmitshur]

@tamird The current milestone for this issue is Go1.8.1, so I believe that's the plan already.

[tamird]

Heh, yet the issue is closed.