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: panic: runtime error: invalid memory address or nil pointer dereference when using -buildmode=shared -linkshared on ppc64le #15770

Open
laboger opened this Issue May 20, 2016 · 10 comments

Comments

Projects
None yet
8 participants
@laboger
Contributor

laboger commented May 20, 2016

Please answer these questions before submitting your issue. Thanks!

  1. What version of Go are you using (go version)?
    go version go1.6.1 linux/ppc64le
    Also fails with latest from tip.
  2. What operating system and processor architecture are you using (go env)?
    Ubuntu 16.04
    GOARCH="ppc64le"
    GOBIN=""
    GOEXE=""
    GOHOSTARCH="ppc64le"
    GOHOSTOS="linux"
    GOOS="linux"
    GOPATH=""
    GORACE=""
    GOROOT="/usr/lib/go-1.6"
    GOTOOLDIR="/usr/lib/go-1.6/pkg/tool/linux_ppc64le"
    GO15VENDOREXPERIMENT="1"
    CC="gcc"
    GOGCCFLAGS="-fPIC -pthread -fmessage-length=0"
    CXX="g++"
    CGO_ENABLED="1"
  3. What did you do?
    If possible, provide a recipe for reproducing the error.
    A complete runnable program is good.
    A link on play.golang.org is best.

Tried to build kubernetes

  1. What did you expect to see?
    Successful build
  2. What did you see instead?
    Failed build.

First, with the cloned code as is, the error is: relocation truncated to fit: R_PPC64_REL24 from several lines due to the size of the packages and binary getting too large. I believe the use of shared libraries should help this problem, so I modified hack/lib/golang.sh to use -buildmode=shared and -linkshared.
go install "${goflags[@]:+${goflags[@]}}" -x -buildmode=shared -ldflags "${goldflags} -linkshared" "${nonstatics[@]:+${nonstatics[@]}}

After adding that I get this error:

/usr/lib/go-1.6/pkg/tool/linux_ppc64le/link -o $WORK/lib.so -L $WORK -installsuffix dynlink -buildmode=shared -X k8s.io/kubernetes/pkg/version.buildDate=2016-05-20T14:18:29Z -X k8s.io/kubernetes/pkg/version.gitCommit=b7a31ad2615524cefcb82ed4b3832e2105147410 -X k8s.io/kubernetes/pkg/version.gitTreeState=dirty -X k8s.io/kubernetes/pkg/version.gitVersion=v1.3.0-alpha.4.191+b7a31ad2615524-dirty -X k8s.io/kubernetes/pkg/version.gitMajor=1 -X k8s.io/kubernetes/pkg/version.gitMinor=3+ -linkshared -extld=powerpc64le-linux-gnu-gcc runtime/cgo=/usr/lib/go-1.6/pkg/linux_ppc64le_dynlink/runtime/cgo.a
//# /tmp/go-build298159653/lib.so
missing Go type information for global symbol: k8s.io/kubernetes/pkg/version.buildDate size 16
missing Go type information for global symbol: k8s.io/kubernetes/pkg/version.gitCommit size 16
missing Go type information for global symbol: k8s.io/kubernetes/pkg/version.gitMajor size 16
missing Go type information for global symbol: k8s.io/kubernetes/pkg/version.gitMinor size 16
missing Go type information for global symbol: k8s.io/kubernetes/pkg/version.gitTreeState size 16
missing Go type information for global symbol: k8s.io/kubernetes/pkg/version.gitVersion size 16
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x8 pc=0x1172dc]

goroutine 1 [running]:
panic(0x260e40, 0xc82000e160)
/usr/lib/go-1.6/src/runtime/panic.go:464 +0x3a0
cmd/link/internal/ld.defgotype(0xc821609680, 0x12)
/usr/lib/go-1.6/src/cmd/link/internal/ld/dwarf.go:1101 +0x3adc
cmd/link/internal/ld.Dwarfemitdebugsections()
/usr/lib/go-1.6/src/cmd/link/internal/ld/dwarf.go:2120 +0x960
cmd/link/internal/ppc64.asmb()
/usr/lib/go-1.6/src/cmd/link/internal/ppc64/asm.go:905 +0x1308
cmd/link/internal/ld.Ldmain()
/usr/lib/go-1.6/src/cmd/link/internal/ld/pobj.go:248 +0x20f4
cmd/link/internal/ppc64.Main()
/usr/lib/go-1.6/src/cmd/link/internal/ppc64/obj.go:44 +0x28
main.main()
/usr/lib/go-1.6/src/cmd/link/main.go:36 +0x540

To reproduce:
git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
make

Similar error happens with go built from latest master but the stack is somewhat different. I did try removing the -X options to the link and the messages about "missing Go type... " didn't appear but the panic still happened.

/home/boger/golang/upstream/go/pkg/tool/linux_ppc64le/link -o $WORK/lib.so -L $WORK -installsuffix dynlink -buildmode=shared -X k8s.io/kubernetes/pkg/version.buildDate=2016-05-20T14:31:11Z -X k8s.io/kubernetes/pkg/version.gitCommit=b7a31ad2615524cefcb82ed4b3832e2105147410 -X k8s.io/kubernetes/pkg/version.gitTreeState=dirty -X k8s.io/kubernetes/pkg/version.gitVersion=v1.3.0-alpha.4.191+b7a31ad2615524-dirty -X k8s.io/kubernetes/pkg/version.gitMajor=1 -X k8s.io/kubernetes/pkg/version.gitMinor=3+ -linkshared -extld=powerpc64le-linux-gnu-gcc runtime/cgo=/home/boger/golang/upstream/go/pkg/linux_ppc64le_dynlink/runtime/cgo.a
//# /tmp/go-build839806022/lib.so
go.link.addmoduledata: missing Go type information for global symbol: k8s.io/kubernetes/pkg/version.buildDate size 16
go.link.addmoduledata: missing Go type information for global symbol: k8s.io/kubernetes/pkg/version.gitCommit size 16
go.link.addmoduledata: missing Go type information for global symbol: k8s.io/kubernetes/pkg/version.gitMajor size 16
go.link.addmoduledata: missing Go type information for global symbol: k8s.io/kubernetes/pkg/version.gitMinor size 16
go.link.addmoduledata: missing Go type information for global symbol: k8s.io/kubernetes/pkg/version.gitTreeState size 16
go.link.addmoduledata: missing Go type information for global symbol: k8s.io/kubernetes/pkg/version.gitVersion size 16
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x101c84]

goroutine 1 [running]:
panic(0x1f6d00, 0xc420010120)
/home/boger/golang/upstream/go/src/runtime/panic.go:500 +0x3a8
cmd/link/internal/ld.newtype(0xc421fafee0, 0xc420012360)
/home/boger/golang/upstream/go/src/cmd/link/internal/ld/dwarf.go:998 +0x3ab4
cmd/link/internal/ld.defgotype(0xc421fafee0, 0x12)
/home/boger/golang/upstream/go/src/cmd/link/internal/ld/dwarf.go:854 +0x3fc
cmd/link/internal/ld.dwarfgeneratedebugsyms()
/home/boger/golang/upstream/go/src/cmd/link/internal/ld/dwarf.go:1982 +0x930
cmd/link/internal/ld.dodata()
/home/boger/golang/upstream/go/src/cmd/link/internal/ld/data.go:1741 +0x3780
cmd/link/internal/ld.Ldmain()
/home/boger/golang/upstream/go/src/cmd/link/internal/ld/pobj.go:211 +0x1630
cmd/link/internal/ppc64.Main()
/home/boger/golang/upstream/go/src/cmd/link/internal/ppc64/obj.go:45 +0x28
main.main()
/home/boger/golang/upstream/go/src/cmd/link/main.go:36 +0x4c4

@ianlancetaylor ianlancetaylor added this to the Go1.8 milestone May 20, 2016

@laboger

This comment has been minimized.

Contributor

laboger commented May 25, 2016

How much of the -buildmode=shared -linkshared options should work with ppc64le? I see it is mentioned in the Go 1.6 release notes as being supported for ppc64le but I have not used it before.

I've been trying various ways to use it but can't make it work.

From looking through various documentation I need to make sure I have libstd.so, and possibly libcmd.so. When I try to build using -buildmode=shared I am getting errors like this:

/home/boger/golang/ibm-go1.6/go/pkg/tool/linux_ppc64le/link -o $WORK/lib.so -L $WORK -installsuffix dynlink -buildmode=shared -X k8s.io/kubernetes/pkg/version.buildDate=2016-05-25T18:15:36Z -X k8s.io/kubernetes/pkg/version.gitCommit=025b0172774770f0d5eee3e9604c1a2d938976e0 -X k8s.io/kubernetes/pkg/version.gitTreeState=dirty -X k8s.io/kubernetes/pkg/version.gitVersion=v1.3.0-alpha.4.474+025b0172774770-dirty -X k8s.io/kubernetes/pkg/version.gitMajor=1 -X k8s.io/kubernetes/pkg/version.gitMinor=3+ -v -extldflags -Wl,--print-map -extld=powerpc64le-linux-gnu-gcc runtime/cgo=/home/boger/golang/ibm-go1.6/go/pkg/linux_ppc64le_dynlink/runtime/cgo.a

sync/atomic.StorePointer: sync/atomic.StoreUintptr: not defined
sync/atomic.SwapPointer: sync/atomic.SwapUintptr: not defined
sync/atomic.CompareAndSwapPointer: sync/atomic.CompareAndSwapUintptr: not defined
runtime.sync_atomic_CompareAndSwapUintptr·f: sync/atomic.CompareAndSwapUintptr: not defined
runtime.sync_atomic_StoreUintptr·f: sync/atomic.StoreUintptr: not defined
runtime.sync_atomic_SwapUintptr·f: sync/atomic.SwapUintptr: not defined

I can see that the symbol sync/atomic.StoreUintptr is in my libstd.so, but it is not finding it, unless I need to do something to get it to find it.

@mwhudson

This comment has been minimized.

Contributor

mwhudson commented May 25, 2016

It should work, but hasn't been deeply tested. I suspect that it's the -X
arguments that are causing the problems you initially reported.

I don't understand that second link failure, it seems to be trying to link
runtime/cgo only, which makes no real sense. What commands are you running?

On 26 May 2016 at 06:33, Lynn Boger notifications@github.com wrote:

How much of the -buildmode=shared -linkshared options should work with
ppc64le? I see it is mentioned in the Go 1.6 release notes as being
supported for ppc64le but I have not used it before.

I've been trying various ways to use it but can't make it work.

From looking through various documentation I need to make sure I have
libstd.so, and possibly libcmd.so. When I try to build using
-buildmode=shared I am getting errors like this:

/home/boger/golang/ibm-go1.6/go/pkg/tool/linux_ppc64le/link -o
$WORK/lib.so -L $WORK -installsuffix dynlink -buildmode=shared -X
k8s.io/kubernetes/pkg/version.buildDate=2016-05-25T18:15:36Z -X
k8s.io/kubernetes/pkg/version.gitCommit=025b0172774770f0d5eee3e9604c1a2d938976e0
-X k8s.io/kubernetes/pkg/version.gitTreeState=dirty -X
k8s.io/kubernetes/pkg/version.gitVersion=v1.3.0-alpha.4.474+025b0172774770-dirty
-X k8s.io/kubernetes/pkg/version.gitMajor=1 -X
k8s.io/kubernetes/pkg/version.gitMinor=3+ -v -extldflags -Wl,--print-map
-extld=powerpc64le-linux-gnu-gcc
runtime/cgo=/home/boger/golang/ibm-go1.6/go/pkg/linux_ppc64le_dynlink/runtime/cgo.a

sync/atomic.StorePointer: sync/atomic.StoreUintptr: not defined

sync/atomic.SwapPointer: sync/atomic.SwapUintptr: not defined

sync/atomic.CompareAndSwapPointer: sync/atomic.CompareAndSwapUintptr: not
defined

runtime.sync_atomic_CompareAndSwapUintptr·f:
sync/atomic.CompareAndSwapUintptr: not defined

runtime.sync_atomic_StoreUintptr·f: sync/atomic.StoreUintptr: not defined

runtime.sync_atomic_SwapUintptr·f: sync/atomic.SwapUintptr: not defined

I can see that the symbol sync/atomic.StoreUintptr is in my libstd.so, but
it is not finding it, unless I need to do something to get it to find it.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#15770 (comment)

@mwhudson

This comment has been minimized.

Contributor

mwhudson commented May 26, 2016

I can't reproduce this (with the go 1.6.2 that's on yakkety):

(yakkety-ppc64el)root@diamond:~/kubernetes# git diff
diff --git a/hack/lib/golang.sh b/hack/lib/golang.sh
index 0ff6e97..2e766e7 100755
--- a/hack/lib/golang.sh
+++ b/hack/lib/golang.sh
@@ -454,7 +454,7 @@ kube::golang::build_binaries_for_platform() {
   else
     # Use go install.
     if [[ "${#nonstatics[@]}" != 0 ]]; then
-      go install "${goflags[@]:+${goflags[@]}}" \
+      go install -buildmode=shared -linkshared
"${goflags[@]:+${goflags[@]}}" \
         -ldflags "${goldflags}" \
         "${nonstatics[@]:+${nonstatics[@]}}"
     fi
(yakkety-ppc64el)root@diamond:~/kubernetes# make
hack/build-go.sh
Go version: go version go1.6.2 linux/ppc64le
+++ [0526 00:04:29] Building the toolchain targets:
    k8s.io/kubernetes/hack/cmd/teststale
+++ [0526 00:04:31] Building go targets for linux/ppc64le:
    cmd/kube-dns
    cmd/kube-proxy
    cmd/kube-apiserver
    cmd/kube-controller-manager
    cmd/kubelet
    cmd/kubemark
    cmd/hyperkube
    federation/cmd/federation-apiserver
    federation/cmd/federation-controller-manager
    plugin/cmd/kube-scheduler
    cmd/kubectl
    cmd/integration
    cmd/gendocs
    cmd/genkubedocs
    cmd/genman
    cmd/genyaml
    cmd/mungedocs
    cmd/genbashcomp
    cmd/genswaggertypedocs
    cmd/linkcheck
    examples/k8petstore/web-server/src
    vendor/github.com/onsi/ginkgo/ginkgo
    test/e2e/e2e.test
    test/e2e_node/e2e_node.test
+++ [0526 00:07:45] Placing binaries
(yakkety-ppc64el)root@diamond:~/kubernetes# echo $?
0

I doubt something between 1.6.1 and 1.6.2 fixed this but who knows.

On 26 May 2016 at 09:35, Michael Hudson-Doyle michael.hudson@canonical.com
wrote:

It should work, but hasn't been deeply tested. I suspect that it's the -X
arguments that are causing the problems you initially reported.

I don't understand that second link failure, it seems to be trying to link
runtime/cgo only, which makes no real sense. What commands are you running?

On 26 May 2016 at 06:33, Lynn Boger notifications@github.com wrote:

How much of the -buildmode=shared -linkshared options should work with
ppc64le? I see it is mentioned in the Go 1.6 release notes as being
supported for ppc64le but I have not used it before.

I've been trying various ways to use it but can't make it work.

From looking through various documentation I need to make sure I have
libstd.so, and possibly libcmd.so. When I try to build using
-buildmode=shared I am getting errors like this:

/home/boger/golang/ibm-go1.6/go/pkg/tool/linux_ppc64le/link -o
$WORK/lib.so -L $WORK -installsuffix dynlink -buildmode=shared -X
k8s.io/kubernetes/pkg/version.buildDate=2016-05-25T18:15:36Z -X
k8s.io/kubernetes/pkg/version.gitCommit=025b0172774770f0d5eee3e9604c1a2d938976e0
-X k8s.io/kubernetes/pkg/version.gitTreeState=dirty -X
k8s.io/kubernetes/pkg/version.gitVersion=v1.3.0-alpha.4.474+025b0172774770-dirty
-X k8s.io/kubernetes/pkg/version.gitMajor=1 -X
k8s.io/kubernetes/pkg/version.gitMinor=3+ -v -extldflags -Wl,--print-map
-extld=powerpc64le-linux-gnu-gcc
runtime/cgo=/home/boger/golang/ibm-go1.6/go/pkg/linux_ppc64le_dynlink/runtime/cgo.a

sync/atomic.StorePointer: sync/atomic.StoreUintptr: not defined

sync/atomic.SwapPointer: sync/atomic.SwapUintptr: not defined

sync/atomic.CompareAndSwapPointer: sync/atomic.CompareAndSwapUintptr: not
defined

runtime.sync_atomic_CompareAndSwapUintptr·f:
sync/atomic.CompareAndSwapUintptr: not defined

runtime.sync_atomic_StoreUintptr·f: sync/atomic.StoreUintptr: not defined

runtime.sync_atomic_SwapUintptr·f: sync/atomic.SwapUintptr: not defined

I can see that the symbol sync/atomic.StoreUintptr is in my libstd.so,
but it is not finding it, unless I need to do something to get it to find
it.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#15770 (comment)

@laboger

This comment has been minimized.

Contributor

laboger commented May 26, 2016

Building kubernetes is new to me so I'm still learning about the makefiles and what should get built. And it seems to behave differently as commits are added to it, so the behavior is not consistent.

If you pull from the latest then you must update the hack/lib/golang.sh file to enable builds for ppc64le.

+++ b/hack/lib/golang.sh
@@ -69,7 +69,7 @@ else
linux/amd64
linux/arm
linux/arm64

  • #linux/ppc64le # temporarily disabled due to a linking error
  • linux/ppc64le # temporarily disabled due to a linking error
    )

@@ -79,7 +79,7 @@ else
linux/386
linux/arm
linux/arm64

  • #linux/ppc64le # temporarily disabled due to a linking error
  • linux/ppc64le # temporarily disabled due to a linking error
    darwin/amd64
    darwin/386
    windows/amd64

The original error happens when building the hyperkube binary, and that error was a relocation truncation error due to the text section getting too large for the GNU linker to handle. After the original failure, in some later commits it does build successfully, it just depends on the size that it ends up being or the length for the branch targets. In any case, I was hoping that the use of -buildmode=shared -linkshared would resolve the original issue and allow the build to succeed but maybe that is a wrong assumption. In any case I would like to understand how the buildmode and linkshared options should be used in this case even if it doesn't solve my original problem.

If the build of the hyperkube binary succeeds (without the -buildmode=shared -linkshared options) you should see these:
./_output/local/bin/linux/ppc64le/hyperkube
./_output/local/go/bin/hyperkube

Here's what I tried, and maybe I'm not using the options correctly.

I first did:
go install -buildmode=shared std

In my experiments, when I add -buildmode=shared -linkshared to 'go install' in golang.sh it doesn't build the hyperkube binary so it's not really doing what it needs to do. Not sure if that is expected when using those options.
When I added just -bulidmode=shared, I get the errors I posted earlier, maybe that that is incorrect usage of the options.

Any comments or advice would be helpful.

@laboger

This comment has been minimized.

Contributor

laboger commented Jun 1, 2016

@mwhudson
I am not able to reproduce the original error. After lots of experimentation I can see that I was misunderstanding how these options should work. It appears that each package that you want to be built as a shared library must be explicitly built with the -buildmode=shared -linkshared options. I was working under the false assumption that the dependent packages would also get built as shared.

I think I have found a real bug with the used of -linkshared and -buildmode and not sure if it is ppc64le only. I can change the title or close this one and open a new one.

If std has been built as a shared library and you try to use -buildmode=shared -linkshared with something that imports golang.org/x/sys/unix, you will get errors like this:

host link: "powerpc64le-linux-gnu-gcc" "-m64" "-gdwarf-2" "-Wl,-znow" "-o" "/tmp/go-build873207612/k8s.io/kubernetes/cmd/kubelet/_obj/exe/a.out" "-rdynamic" "/tmp/go-link-758373105/go.o" "/tmp/go-link-758373105/000000.o" "/tmp/go-link-758373105/000001.o" "/tmp/go-link-758373105/000002.o" "-L/home/boger/golang/go1.6/go/pkg/linux_ppc64le_dynlink/" "-Wl,-rpath=/home/boger/golang/go1.6/go/pkg/linux_ppc64le_dynlink/" "-lstd" "-g" "-O2" "-g" "-O2" "-g" "-O2"
/home/boger/golang/go1.6/go/pkg/tool/linux_ppc64le/link: running powerpc64le-linux-gnu-gcc failed: exit status 1
/usr/bin/ld: /tmp/go-link-758373105/go.o: In function local.k8s.io/kubernetes/vendor/golang.org/x/sys/unix.Syscall': (.text+0xbb0560): call tosyscall.Syscall' lacks nop, can't restore toc; recompile with -fPIC
/usr/bin/ld: /tmp/go-link-758373105/go.o: In function local.k8s.io/kubernetes/vendor/golang.org/x/sys/unix.Syscall': (.text+0xbb0560): unresolvable R_PPC64_REL24 againstsyscall.Syscall'
/usr/bin/ld: /tmp/go-link-758373105/go.o: In function local.k8s.io/kubernetes/vendor/golang.org/x/sys/unix.Syscall6': (.text+0xbb0570): call tosyscall.Syscall6' lacks nop, can't restore toc; recompile with -fPIC
/usr/bin/ld: /tmp/go-link-758373105/go.o: In function local.k8s.io/kubernetes/vendor/golang.org/x/sys/unix.Syscall6': (.text+0xbb0570): unresolvable R_PPC64_REL24 againstsyscall.Syscall6'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

The instruction it is complaining about is a simple branch instruction. The asm code looks like this:
// Just jump to package syscall's implementation for all these functions.
// The runtime may know about them.

TEXT ·Syscall(SB),NOSPLIT,$0-56
BR syscall·Syscall(SB)

TEXT ·Syscall6(SB),NOSPLIT,$0-80
BR syscall·Syscall6(SB)

TEXT ·RawSyscall(SB),NOSPLIT,$0-56
BR syscall·RawSyscall(SB)

TEXT ·RawSyscall6(SB),NOSPLIT,$0-80
BR syscall·RawSyscall6(SB)

The ppc64le asm is just a branch.

@laboger

This comment has been minimized.

Contributor

laboger commented Jun 1, 2016

Here is a simple way to reproduce the problem I found. There are actually two problems.

  1. If you use the -linkshared option with go get, it does not use linux_ppc64le_dynlink as the install directory.
    go get -u -x -linkshared golang.org/x/sys/unix
    cd .
    git clone https://go.googlesource.com/sys /home/boger/golang.work/src/golang.org/x/sys
    cd /home/boger/golang.work/src/golang.org/x/sys
    git submodule update --init --recursive
    cd /home/boger/golang.work/src/golang.org/x/sys
    git show-ref
    cd /home/boger/golang.work/src/golang.org/x/sys
    git submodule update --init --recursive
    WORK=/tmp/go-build954411439
    mkdir -p $WORK/golang.org/x/sys/unix/_obj/
    mkdir -p $WORK/golang.org/x/sys/
    cd /home/boger/golang.work/src/golang.org/x/sys/unix
    /home/boger/golang/go1.6/go/pkg/tool/linux_ppc64le/compile -o $WORK/golang.org/x/sys/unix.a -trimpath $WORK -dynlink -p golang.org/x/sys/unix -installsuffix dynlink -buildid c6471c5554bcf97afeb2aba390b30ab58fbaf41d -D _/home/boger/golang.work/src/golang.org/x/sys/unix -I $WORK -pack -asmhdr $WORK/golang.org/x/sys/unix/_obj/go_asm.h ./bluetooth_linux.go ./constants.go ./env_unix.go ./env_unset.go ./flock.go ./race0.go ./sockcmsg_linux.go ./sockcmsg_unix.go ./str.go ./syscall.go ./syscall_linux.go ./syscall_linux_ppc64x.go ./syscall_unix.go ./zerrors_linux_ppc64le.go ./zsyscall_linux_ppc64le.go ./zsysnum_linux_ppc64le.go ./ztypes_linux_ppc64le.go
    /home/boger/golang/go1.6/go/pkg/tool/linux_ppc64le/asm -o $WORK/golang.org/x/sys/unix/_obj/asm.o -trimpath $WORK -I $WORK/golang.org/x/sys/unix/_obj/ -I /home/boger/golang/go1.6/go/pkg/include -D GOOS_linux -D GOARCH_ppc64le -D=GOBUILDMODE_shared=1 -dynlink ./asm.s
    /home/boger/golang/go1.6/go/pkg/tool/linux_ppc64le/asm -o $WORK/golang.org/x/sys/unix/_obj/asm_linux_ppc64x.o -trimpath $WORK -I $WORK/golang.org/x/sys/unix/_obj/ -I /home/boger/golang/go1.6/go/pkg/include -D GOOS_linux -D GOARCH_ppc64le -D=GOBUILDMODE_shared=1 -dynlink ./asm_linux_ppc64x.s
    pack r $WORK/golang.org/x/sys/unix.a $WORK/golang.org/x/sys/unix/_obj/asm.o $WORK/golang.org/x/sys/unix/_obj/asm_linux_ppc64x.o # internal
    mkdir -p /home/boger/golang.work/pkg/linux_ppc64le/golang.org/x/sys/
    cp $WORK/golang.org/x/sys/unix.a /home/boger/golang.work/pkg/linux_ppc64le/golang.org/x/sys/unix.a
  2. If I use go get -d followed by go install -linkshared, it generates the correct directory:
    go install -x -linkshared golang.org/x/sys/unix
    WORK=/tmp/go-build696097881
    mkdir -p $WORK/golang.org/x/sys/unix/_obj/
    mkdir -p $WORK/golang.org/x/sys/
    cd /home/boger/golang.work/src/golang.org/x/sys/unix
    /home/boger/golang/go1.6/go/pkg/tool/linux_ppc64le/compile -o $WORK/golang.org/x/sys/unix.a -trimpath $WORK -dynlink -p golang.org/x/sys/unix -installsuffix dynlink -buildid c6471c5554bcf97afeb2aba390b30ab58fbaf41d -D _/home/boger/golang.work/src/golang.org/x/sys/unix -I $WORK -pack -asmhdr $WORK/golang.org/x/sys/unix/_obj/go_asm.h ./bluetooth_linux.go ./constants.go ./env_unix.go ./env_unset.go ./flock.go ./race0.go ./sockcmsg_linux.go ./sockcmsg_unix.go ./str.go ./syscall.go ./syscall_linux.go ./syscall_linux_ppc64x.go ./syscall_unix.go ./zerrors_linux_ppc64le.go ./zsyscall_linux_ppc64le.go ./zsysnum_linux_ppc64le.go ./ztypes_linux_ppc64le.go
    /home/boger/golang/go1.6/go/pkg/tool/linux_ppc64le/asm -o $WORK/golang.org/x/sys/unix/_obj/asm.o -trimpath $WORK -I $WORK/golang.org/x/sys/unix/_obj/ -I /home/boger/golang/go1.6/go/pkg/include -D GOOS_linux -D GOARCH_ppc64le -D=GOBUILDMODE_shared=1 -dynlink ./asm.s
    /home/boger/golang/go1.6/go/pkg/tool/linux_ppc64le/asm -o $WORK/golang.org/x/sys/unix/_obj/asm_linux_ppc64x.o -trimpath $WORK -I $WORK/golang.org/x/sys/unix/_obj/ -I /home/boger/golang/go1.6/go/pkg/include -D GOOS_linux -D GOARCH_ppc64le -D=GOBUILDMODE_shared=1 -dynlink ./asm_linux_ppc64x.s
    pack r $WORK/golang.org/x/sys/unix.a $WORK/golang.org/x/sys/unix/_obj/asm.o $WORK/golang.org/x/sys/unix/_obj/asm_linux_ppc64x.o # internal
    mkdir -p /home/boger/golang.work/pkg/linux_ppc64le_dynlink/golang.org/x/sys/
    cp $WORK/golang.org/x/sys/unix.a /home/boger/golang.work/pkg/linux_ppc64le_dynlink/golang.org/x/sys/unix.a
  3. But then if I use this testcase with the unix package I see the same errors as above:
    package main

import (
"fmt"
"golang.org/x/sys/unix"
)

func main() {
fmt.Printf("pagesize: %d \n", unix.Getpagesize())
}

I see multiple errors.
go build -linkshared sharedtest.go

command-line-arguments

/home/boger/golang/go1.6/go/pkg/tool/linux_ppc64le/link: running gcc failed: exit status 1
/usr/bin/ld: /tmp/go-link-460846081/go.o: In function local.golang.org/x/sys/unix.(*mmapper).Lock': (.text+0x10c4): call tosync.(_Mutex).Lock' lacks nop, can't restore toc; recompile with -fPIC
/usr/bin/ld: /tmp/go-link-460846081/go.o: In function local.golang.org/x/sys/unix.(_mmapper).Lock': (.text+0x10c4): unresolvable R_PPC64_REL24 against sync.(*Mutex).Lock'
/usr/bin/ld: /tmp/go-link-460846081/go.o: In functionlocal.golang.org/x/sys/unix.(_mmapper).Unlock': (.text+0x1114): call to sync.(_Mutex).Unlock' lacks nop, can't restore toc; recompile with -fPIC
/usr/bin/ld: /tmp/go-link-460846081/go.o: In function local.golang.org/x/sys/unix.(*mmapper).Unlock': (.text+0x1114): unresolvable R_PPC64_REL24 againstsync.(*Mutex).Unlock'
/usr/bin/ld: /tmp/go-link-460846081/go.o: In function local.golang.org/x/sys/unix.Syscall': (.text+0x1128): call tosyscall.Syscall' lacks nop, can't restore toc; recompile with -fPIC
/usr/bin/ld: /tmp/go-link-460846081/go.o: In function local.golang.org/x/sys/unix.Syscall': (.text+0x1128): unresolvable R_PPC64_REL24 againstsyscall.Syscall'
/usr/bin/ld: /tmp/go-link-460846081/go.o: In function local.golang.org/x/sys/unix.Syscall6': (.text+0x1138): call tosyscall.Syscall6' lacks nop, can't restore toc; recompile with -fPIC
/usr/bin/ld: /tmp/go-link-460846081/go.o: In function local.golang.org/x/sys/unix.Syscall6': (.text+0x1138): unresolvable R_PPC64_REL24 againstsyscall.Syscall6'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

@marguerite

This comment has been minimized.

marguerite commented Jul 9, 2016

same problem happened here in x86_64 with go 1.6.2 too. the problem looked like the same no matter with '-x' option or not.

go install -buildmode=shared -linkshared -s -v -p 4 golang.org/x/text/...

[ 53s] golang.org/x/text/unicode
[ 53s] golang.org/x/text/unicode/rangetable
[ 57s] panic: runtime error: invalid memory address or nil pointer dereference
[ 57s] [signal 0xb code=0x1 addr=0x71 pc=0x414d9b]
[ 57s]
[ 57s] goroutine 20 [running]:
[ 57s] panic(0x93d400, 0xc8200101e0)
[ 57s] /usr/lib64/go/src/runtime/panic.go:481 +0x3e6
[ 57s] main.(_builder).install(0xc820184d90, 0xc8202616c0, 0x0, 0x0)
[ 57s] /usr/lib64/go/src/cmd/go/build.go:1630 +0x5b
[ 57s] main.(_builder).do.func1(0xc8202616c0)
[ 57s] /usr/lib64/go/src/cmd/go/build.go:1260 +0x3b2
[ 57s] main.(_builder).do.func2(0xc8202b8bd0, 0xc820184d90, 0xc8204f6a40)
[ 57s] /usr/lib64/go/src/cmd/go/build.go:1317 +0x156
[ 57s] created by main.(_builder).do
[ 57s] /usr/lib64/go/src/cmd/go/build.go:1323 +0x39e

@rsc rsc modified the milestones: Go1.9, Go1.8 Nov 11, 2016

@bradfitz

This comment has been minimized.

Member

bradfitz commented Jun 7, 2017

@laboger, what's the status here? Go1.10?

@bradfitz bradfitz modified the milestones: Go1.10, Go1.9 Jun 7, 2017

@laboger

This comment has been minimized.

Contributor

laboger commented Sep 29, 2017

I'm sorry I didn't see this sooner, sometimes I don't see the notifications for @laboger, not sure why or how to find out.

I just tried this, it still fails. This needs to be compiled as position independent (-shared) but a direct branch to an external target like this is not what the ext linker expects in position independent code. It is the following BR instructions that it is complaining about.

TEXT ·Syscall(SB),NOSPLIT,$0-56
BR syscall·Syscall(SB)

TEXT ·Syscall6(SB),NOSPLIT,$0-80
BR syscall·Syscall6(SB)

TEXT ·RawSyscall(SB),NOSPLIT,$0-56
BR syscall·RawSyscall(SB)

TEXT ·RawSyscall6(SB),NOSPLIT,$0-80
BR syscall·RawSyscall6(SB)

It should probably be done one way for PIC and another for non-PIC.

@laboger

This comment has been minimized.

Contributor

laboger commented Oct 2, 2017

I looked at this a bit... I think what needs to be done is if there is a BR (branch) with the target too far or in a different name space, then it needs to generate a code sequence like a trampoline, if compiled with -dynlink or -shared.

@rsc rsc modified the milestones: Go1.10, Go1.11 Nov 22, 2017

@gopherbot gopherbot modified the milestones: Go1.11, Unplanned May 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment