Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
cherrymui opened this issue Dec 1, 2022 · 7 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge

Comments

@cherrymui
Copy link
Member

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.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Dec 1, 2022
@ianlancetaylor
Copy link
Contributor

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

@ianlancetaylor
Copy link
Contributor

ianlancetaylor commented Dec 1, 2022

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

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

@cherrymui
Copy link
Member Author

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

@gopherbot
Copy link

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Projects
None yet
Development

No branches or pull requests

3 participants