misc/cgo/testshared: TestCgoExecutable fails on linux/arm (Raspberry Pi 2)

[eliasnaur]

Please answer these questions before submitting your issue. Thanks!

1. What version of Go are you using (go version)?
   go version devel +a101b85 Sun May 15 20:56:39 2016 +0000 linux/arm
2. What operating system and processor architecture are you using (go env)?

pi@raspberrypi ~/go/src $ uname -a
Linux raspberrypi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux

pi@raspberrypi ~/go/src $ ../bin/go env
GOARCH="arm"
GOBIN=""
GOEXE=""
GOHOSTARCH="arm"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/home/pi/go"
GOTOOLDIR="/home/pi/go/pkg/tool/linux_arm"
CC="gcc"
GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build235241708=/tmp/go-build"
CXX="g++"
CGO_ENABLED="1"

1. What did you do?
   GOROOT_BOOTSTRAP=$HOME/go1.6 ./all.bash
2. What did you expect to see?
   All tests passed, just like the linux/arm builders on build.golang.org
3. What did you see instead?

##### ../misc/cgo/testshared
--- FAIL: TestCgoExecutable (13.36s)
    shared_test.go:41: executing ./bin/execgo (cgo executable) failed exit status 2:
        runtime: typeOff 0x165a0 base 0x13d08 not in ranges:
            types 0x76f16820 etypes 0x76f41b80
            types 0x10010 etypes 0x1201c
        fatal error: runtime: type offset base pointer out of range

        runtime stack:
        runtime.throw(0x76f0815b, 0x2e)
            /home/pi/go/src/runtime/panic.go:566 +0x80 fp=0x7ee25398 sp=0x7ee2538c
        runtime.(*_type).typeOff(0x13d08, 0x165a0, 0x2d)
            /home/pi/go/src/runtime/type.go:230 +0x27c fp=0x7ee253d8 sp=0x7ee25398
        runtime.additab(0x76f795f8, 0x1)
            /home/pi/go/src/runtime/iface.go:102 +0xf8 fp=0x7ee25464 sp=0x7ee253d8
        runtime.itabsinit()
            /home/pi/go/src/runtime/iface.go:149 +0xac fp=0x7ee2548c sp=0x7ee25464
        runtime.schedinit()
            /home/pi/go/src/runtime/proc.go:452 +0x7c fp=0x7ee254b0 sp=0x7ee2548c
        runtime.rt0_go(0x7ee25644, 0x76ddc000, 0x7ee25644, 0x1, 0xbea0, 0x0, 0x0, 0xbeb8, 0x0, 0x0, ...)
            /home/pi/go/src/runtime/asm_arm.s:61 +0x94 fp=0x7ee254f0 sp=0x7ee254b0
FAIL
exit status 1
FAIL    _/home/pi/go/misc/cgo/testshared    203.168s
2016/05/16 10:00:31 Failed: exit status 1

[ianlancetaylor]

CC @crawshaw

[ianlancetaylor]

Can you put the execgo binary somewhere we can look at it?

[eliasnaur]

Of course. I hope it can wait until Saturday, where I can access the Pi2 again.

[eliasnaur]

Here is the execgo executable from the TestCgoExecutable test, as well as the libruntime,sync-atomic.so it is linked against. Both files were created by running "go test" in the misc/cgo/testshared directory, with the os.Remove calls commented out.

cgotest.zip

[eliasnaur]

TestCgoExecutable completes successfully on go 1.6.2, so this is a regression (at least on this machine. I'm still not sure why the test doesn't fail on the builders). Consider bumping its milestone to Go1.7.

The test failure is completely reproducible for me, so here's what git bisect had to say:

95df0c6ab93f6a42bdc9fd45500fd4d56bfc9add is the first bad commit
commit 95df0c6ab93f6a42bdc9fd45500fd4d56bfc9add
Author: David Crawshaw <crawshaw@golang.org>
Date:   Mon Mar 28 21:51:10 2016 -0400

    cmd/compile, etc: use name offset in method tables

The offending CL 21396 seems plausible.

[crawshaw]

That binary is full of COPY relocations:

$ readelf -r execgo 

Relocation section '.rel.dyn' at offset 0x3a3c contains 17 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00013650  00000115 R_ARM_GLOB_DAT    00000000   runtime.duffzero
00013668  00000315 R_ARM_GLOB_DAT    00000000   __gmon_start__
00013670  00000f15 R_ARM_GLOB_DAT    00013c20   type.TwVfYA92
00013678  00000615 R_ARM_GLOB_DAT    00000000   runtime.writeBarrier
00013c20  00000f14 R_ARM_COPY        00013c20   type.TwVfYA92
00013bd0  00010214 R_ARM_COPY        00013bd0   type.Tm3Esdey
00013bf8  0000ad14 R_ARM_COPY        00013bf8   type.E+zYQ7mG
00013c48  00003514 R_ARM_COPY        00013c48   type.GjUTYvgC
00013c70  00004214 R_ARM_COPY        00013c70   runtime.algarray
00013ce0  00007314 R_ARM_COPY        00013ce0   type.+wnaJbOL
00013d08  0000cb14 R_ARM_COPY        00013d08   type.FzcKhzuU
00013d30  00001b14 R_ARM_COPY        00013d30   go.link.abihash.librun
00013d38  00002714 R_ARM_COPY        00013d38   type.PS96KOYW
00013d60  0000d714 R_ARM_COPY        00013d60   type.ZTzPWLqG
00013da0  0000ba14 R_ARM_COPY        00013da0   type.cZzVjlwW
00013dc8  00009014 R_ARM_COPY        00013dc8   type.XaFOCO3N
00013df0  0000ea14 R_ARM_COPY        00013df0   type.0ZX00qxj

This was fixed on the linux/arm builders by switching to the gold linker in 3c8d6af. Is your toolchain using gold for external linking? (Compiling with -ldflags=-v may give this away.)

[eliasnaur]

I see. On my system,

pi@raspberrypi ~/go/src $ ls -al /usr/bin/ld
lrwxrwxrwx 1 root root 6 Jun 18  2014 /usr/bin/ld -> ld.bfd

I'm running a fairly old rasbian version (based on wheezy) so that explains why it's not using the gold linker. It doesn't even seem to be supported:

pi@raspberrypi ~/go/src $ sudo apt-get install binutils-gold
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 binutils-gold : Depends: binutils (= 2.22-8+deb7u2) but 2.24.51.20140425-1~rpi1rpi2 is to be installed
E: Unable to correct problems, you have held broken packages.

I guess the issue is why building with the -fuse-ld=gold argument succeeds at all.

[crawshaw]

Yes, I was hoping that -fuse-ld=gold would fail in the absence of gold. I suppose we could test for it by running gcc -fuse-ld=gold -Wl,--version and searching the output for "GNU gold".

[gopherbot]

CL https://golang.org/cl/23400 mentions this issue.

[eliasnaur]

Thanks!

[mwhudson]

Huh bizarre, because -fuse-ld=gold without gold does fail sometimes:

##### ../misc/cgo/testshared
2016/05/17 09:26:59 executing go install -installsuffix=5577006791947779410 -buildmode=shared runtime sync/atomic failed exit status 2:
# /tmp/go-build663753573/libruntime,sync-atomic.so
/«PKGBUILDDIR»/pkg/tool/linux_arm64/link: running gcc failed: exit status 1
collect2: fatal error: cannot find 'ld'
compilation terminated.

(from building tip on arm64 ubuntu 14.04, https://launchpadlibrarian.net/259960116/buildlog_ubuntu-trusty-arm64.golang-tip_201605162130.1b86862~ppa1~ubuntu14.04.1_BUILDING.txt.gz)