cmd/link: unhandled R_PPC64_SECTOFF relocation on linux/ppc64le

[laboger]

The following testcase fails to build when using go built from master golang for ppc64le. I pulled the latest source yesterday and built it.

The same test builds and runs successfully with golang on x86_64, and with latest gccgo from trunk on ppc64le.

boger@willow3: ~/gotests$ go version
go version devel +514eb4a Wed Apr 8 18:34:35 2015 +0000 linux/ppc64le
boger@willow3:~/gotests$ go build hello_cgo.go
# command-line-arguments
main.init: unsupported relocation for dynamic symbol stdout (type=2 stype=33)
main.init: unhandled relocation for stdout (type 33 rtype 2)
boger@willow3: ~/gotests$ cat hello_cgo.go
package main


// #include <stdio.h>
// #include <stdlib.h>
import "C"
import "unsafe"

func main() {
    cs := C.CString("Hello, world from C\n")
    C.fputs(cs, (*C.FILE)(C.stdout))
    C.free(unsafe.Pointer(cs))
}

uname -a
Linux willow3 3.16.0-23-generic #31-Ubuntu SMP Tue Oct 21 17:55:08 UTC 2014 ppc64le ppc64le ppc64le GNU/Linux

[bradfitz]

Yes, our ppc64le build is currently broken: http://build.golang.org/

[minux]

internal linking doesn't support stdout.

Even on the well supported linux/amd64, internal linking will fail
to run your example program.

$ go version
go version devel +75c0566 Sat Apr 11 19:36:19 2015 +0000 linux/amd64
$ go run cgo.go
Hello, world from C
$ go run -ldflags "-linkmode internal" cgo.go 
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x80 addr=0x0 pc=0x7fce2d45bc02]

runtime stack:
runtime.throw(0x4881b0, 0x2a)
    .../go/src/runtime/panic.go:543 +0x96
runtime.sigpanic()
    .../go/src/runtime/sigpanic_unix.go:12 +0x5d

goroutine 1 [syscall, locked to thread]:
runtime.cgocall_errno(0x44b9c0, 0xc20804ff68, 0x0)
    .../go/src/runtime/cgocall.go:125 +0x133 fp=0xc20804ff48 sp=0xc20804ff18
main._Cfunc_fputs(0xbc2010, 0x680006f22225ff, 0x0)
    ??:0 +0x3c fp=0xc20804ff68 sp=0xc20804ff48
main.main()
    /tmp/cgo2.go:10 +0x55 fp=0xc20804ff90 sp=0xc20804ff68
runtime.main()
    .../go/src/runtime/proc.go:107 +0x2a7 fp=0xc20804ffe0 sp=0xc20804ff90
runtime.goexit()
    .../go/src/runtime/asm_amd64.s:1671 +0x1 fp=0xc20804ffe8 sp=0xc20804ffe0

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    .../go/src/runtime/asm_amd64.s:1671 +0x1
exit status 2

[minux]

I take a brief look on the linux/amd64 issue.

We are using stdout@plt to reference stdout! How could that ever
work? Maybe it's a cmd/6l problem, but I'm not sure.
(Note the address of stdout passed to fputs is: 0x680006f22225ff,
which is the instructions: jmpq *0x6f222(%rip), pushq $00
used in the plt.)

I thought the problem for stdout was that it uses the COPY relocation,
but apparently after external linking is introduced, internal linking
with stdout regressed. I will dig more and file a separate issue.

The PPC64 problem is unrelated to that though. It's because our
internal linking does not handle R_PPC64_SECTOFF relocation.

[rsc]

Dup of #9411?

[laboger]

When I build golang from master for use with ppc64le I add my own set of
patches as I describe here #11184
because master is missing support for external linking on ppc64le.

If I build using these patches, then the error no longer occurs with
this testcase on ppc64le.

On 06/29/2015 12:38 PM, Russ Cox wrote:

Dup of #9411 #9411?

—
Reply to this email directly or view it on GitHub
#10397 (comment).

[laboger]

This works on ppc64le now that the patches from 11184 are upstream.