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: go version fails on internally linked PIE #37173

Closed
cherrymui opened this issue Feb 11, 2020 · 2 comments
Closed

cmd/link: go version fails on internally linked PIE #37173

cherrymui opened this issue Feb 11, 2020 · 2 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@cherrymui
Copy link
Member

cherrymui commented Feb 11, 2020

What version of Go are you using (go version)?

tip (1c241d2)

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

Related to issue #31861, go version still fails on internally linked PIE.

$ go build -buildmode=pie -ldflags=-linkmode=internal hello.go 
$ go version hello
hello: go version not found

It seems the problem is that for building PIE, we generate dynamic relocations for address references. This includes the address references for the build info, specifically in symbols .go.buildinfo, runtime.buildVersion, and runtime.modinfo. When we generate dynamic relocations, we just leave the bytes in the binary unset (as zero), as the dynamic linker will overwrite it at run time anyway. But go version examines the file, so it won't be able to follow the address references.

I see the following ways for fixing this:

  1. when generating dynamic relocations, also apply the relocations statically (to the address without the base), so the file content can be used to find the reference. However, this will make the linker resolve more relocations that are unnecessary.
  2. only apply the static relocations to specific symbols (namely, .go.buildinfo, runtime.buildVersion, and runtime.modinfo). We need to keep the list of special symbols in sync with the runtime and the go command, though.
  3. teach go version about resolving dynamic relocations. Seems overkill.

@ianlancetaylor @rsc @bcmills for thoughts. I can do the implementation once we decide which way to go.

@cherrymui cherrymui added this to the Go1.15 milestone Feb 11, 2020
@cherrymui
Copy link
Member Author

I think 2 doesn't work, because there are also address references in the string header referenced by those symbols, which also need to apply statically. We'll probably have to do 1...

@gopherbot
Copy link

Change https://golang.org/cl/219199 mentions this issue: cmd/link: also apply R_ADDR relocation statically when internal linking PIE

@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 14, 2020
@golang golang locked and limited conversation to collaborators Feb 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

3 participants