cmd/link: external linking is nondeterministic on linux-arm64-longtest builder

[cherrymui]

Split from #49649.

On the linux-arm64-longtest builder, cmd/go's TestScript/build_issue48319 fails. https://build.golang.org/log/7b3bdfcc706b20aeb4deb0a6b7fb6c73d75670d9

The binary differ because externally-linked binary seems to contain a path of a temporary file.
Build the following code

package main
import "C"
func main() { println("hello") }

The resulting binary contains a symbol (from objdump -t)

0000000000000000 l    df *ABS*  0000000000000000              /tmp/go-link-2380185686/000014.o

which causes the binary content to differ each time.

The builder by default uses the BFD linker, which is GNU ld (GNU Binutils for Debian) 2.35.2.

Interestingly, using the gold linker the resulting binary does not have such a symbol.

@ianlancetaylor @thanm do you know why the BFD linker creates such a symbol, and if there is any way to make it not do so (besides stripping out all the symbols)? Thanks.

[ianlancetaylor]

Do you have the readelf -s --wide output? That shows more precisely what is in the ELF file. Thanks.

[ianlancetaylor]

In any case, the go-link- certainly suggests that this is the file being created by hostlinksetup in cmd/link/internal/ld/lib.go.

And looking at the GNU linker, this may be https://sourceware.org/bugzilla/show_bug.cgi?id=26822. It looks like that was fixed in the GNU binutils 2.36 release (current release is 2.39, I think). The linux-arm64-longtest builder is running GNU ld version 2.35.2. So that is likely where the symbol is coming from.

[cherrymui]

readelf -s --wide output for that symbol is

  1556: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS /tmp/go-link-2380185686/000014.o

Yeah, it looks exactly like https://sourceware.org/bugzilla/show_bug.cgi?id=26822 . Thanks @ianlancetaylor !

Perhaps we could skip the test with older BFD linkers. Or use gold linker on that builder. cc @bcmills (since this is a test in cmd/go)

[ianlancetaylor]

The name of the file suggests that this must be coming from hostobjCopy. I tried running the test locally. I do see a file created with no STT_FILE symbol: the object created by assembling runtime/cgo/gcc_amd64.S. That is a standard assembler file. I bet we can fix this problem by adding .file "FILENAME" directives to all the gcc_*.S files in that directory.

[cherrymui]

Yeah, the file is from hostobjCopy, and it is from that assembly file. I'll try adding the .file directive. Thanks!

[cherrymui]

Yeah, that does work! Thanks, @ianlancetaylor ! I'll send a CL tomorrow.

[gopherbot]

Change https://go.dev/cl/454838 mentions this issue: runtime/cgo: add .file directive to GNU assembly files