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

[Helflym]

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]

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]

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]

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