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: difference between s.P and s.Size #28764

Helflym opened this issue Nov 13, 2018 · 3 comments

cmd/link: difference between s.P and s.Size #28764

Helflym opened this issue Nov 13, 2018 · 3 comments


Copy link

@Helflym Helflym commented Nov 13, 2018

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

go version devel +66fa0ae2e6 Thu Nov 8 14:29:02 2018 -0600 aix/ppc64

Does this issue reproduce with the latest release?

I don't know. But I think so.

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

I'm on aix/ppc64. But I've quickly tried on linux/amd64 and I have the same issue.

What did you do?

This is linked with //go:cgo_import_dynamic. My program looks like this:

package main

import (
 	_ "unsafe"

//go:cgo_import_dynamic libc_exit exit ""
//go:linkname libc_exit libc_exit

var libc_exit uintptr

func main() {
	 fmt.Printf("0x%x\n", &libc_exit)

During XCOFF creation (doxcoff), I'm trying to add a relocation from "libc_exit" symbol to a new needed symbol "exit". (The same can be done in doelf on linux/amd64)
My code looks like:

s := ctxt.Syms.Lookup("libc_exit", 0)
extsym := ctxt.Syms.Lookup(s.Extname(), 0)
// setup of extsym
s.AddAddr(ctxt.Arch, extsym) 

Before this operation, s.Size = 8 and len(s.P) = 0. I'm not sure if it's wanted but as libc_exit is linkname to a bss symbol, it's not that strange.
Therefore, when I do s.AddAddr(ctxt.Arch, extsym), I've s.Size = 16 and len(s.P) = 16. But I don't want that as the relocation will be at off = 8 and "libc_exit" should have only 8 bytes.

So, I've tried with s.SetAddr(ctxt.Arch, 0, extsym) to set these 8 bytes. But in this case, during relocsym I've this error:
libc_exit: invalid relocation exit: 0+8 not in [0,0) (numbers in order: r.Off, s.Size, 0, len(s.P))
because s.P isn't growth during this operation.
If I increase s.P manually, everything is OK:

s.AddBytes(make([]byte, 8))
s.SetAddr(ctxt.Arch, 0, extsym)

Therefore, I'm understanding it's not possible to create such relocation with the current sym functions. This might not be a problem, but the second behavior doesn't seem intended. Is this a bug ?

Copy link

@ianlancetaylor ianlancetaylor commented Nov 13, 2018

You may do better to ask on golang-dev rather than putting this in the form of an issue. The linker code is old and strange--it's a rewrite from the C code used in the Inferno linker. I don't think we're going to change it to make it cleaner, only to fix specific bugs.

Copy link
Contributor Author

@Helflym Helflym commented Nov 13, 2018

Ok thanks, I've asked.
I'll see if a useful answer is given. I might add it here later in order to help anyone who might faces the same problem in the future.

Copy link

@bcmills bcmills commented Nov 19, 2018

No replies so far, but here's the golang-dev thread:

@bcmills bcmills closed this Nov 19, 2018
@golang golang locked and limited conversation to collaborators Nov 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.