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

Closed
Helflym opened this issue Nov 13, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@Helflym
Copy link
Contributor

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 (
 	"fmt"
 	_ "unsafe"
)

//go:cgo_import_dynamic libc_exit exit "libc.so"
//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 ?

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

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.

@Helflym

This comment has been minimized.

Copy link
Contributor Author

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.

@bcmills

This comment has been minimized.

Copy link
Member

commented Nov 19, 2018

No replies so far, but here's the golang-dev thread:
https://groups.google.com/d/msg/golang-dev/QduPoOvWPx0/yOKfMTJ1BwAJ

@bcmills bcmills closed this Nov 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.