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

eliasnaur · 2016-05-16T10:34:29Z

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?
go version devel +a101b85 Sun May 15 20:56:39 2016 +0000 linux/arm
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"

What did you do?
GOROOT_BOOTSTRAP=$HOME/go1.6 ./all.bash
What did you expect to see?
All tests passed, just like the linux/arm builders on build.golang.org
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

The text was updated successfully, but these errors were encountered:

ianlancetaylor · 2016-05-18T01:20:16Z

CC @crawshaw

ianlancetaylor · 2016-05-18T01:25:43Z

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

eliasnaur · 2016-05-18T08:13:53Z

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

eliasnaur · 2016-05-22T01:00:46Z

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 · 2016-05-24T12:10:09Z

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 <[email protected]>
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 · 2016-05-24T14:29:34Z

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 · 2016-05-24T15:06:10Z

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 · 2016-05-24T15:20:32Z

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 · 2016-05-24T18:00:28Z

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

eliasnaur · 2016-05-24T19:13:12Z

Thanks!

mwhudson · 2016-05-24T21:56:25Z

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)

CL 23400 introduced a check to make sure the gold linker is used on ARM host links. The check itself works, but the error checking logic was reversed; fix it. I manually verified that the check now correctly rejects host links on my RPi2 running an ancient rasbian without the gold linker installed. Updates #15696 Change-Id: I927832620f0a60e91a71fdedf8cbd2550247b666 Reviewed-on: https://go-review.googlesource.com/23421 Run-TryBot: Elias Naur <[email protected]> Reviewed-by: David Crawshaw <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>

ianlancetaylor added this to the Go1.7Maybe milestone May 18, 2016

ianlancetaylor assigned crawshaw May 24, 2016

gopherbot closed this as completed in a0abecf May 24, 2016

golang locked and limited conversation to collaborators May 24, 2017

gopherbot added the FrozenDueToAge label May 24, 2017

eternal-flame-AD referenced this issue in gotify/plugin-template Feb 3, 2019

Add makefile

51501bf

rsc unassigned crawshaw Jun 23, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

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

eliasnaur commented May 16, 2016 •

edited

Loading

ianlancetaylor commented May 18, 2016

Uh oh!

ianlancetaylor commented May 18, 2016

Uh oh!

eliasnaur commented May 18, 2016

Uh oh!

eliasnaur commented May 22, 2016

Uh oh!

eliasnaur commented May 24, 2016

Uh oh!

crawshaw commented May 24, 2016 •

edited

Loading

Uh oh!

eliasnaur commented May 24, 2016

Uh oh!

crawshaw commented May 24, 2016

Uh oh!

gopherbot commented May 24, 2016

Uh oh!

eliasnaur commented May 24, 2016

Uh oh!

mwhudson commented May 24, 2016

Uh oh!

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

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

Comments

eliasnaur commented May 16, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ianlancetaylor commented May 18, 2016

Uh oh!

ianlancetaylor commented May 18, 2016

Uh oh!

eliasnaur commented May 18, 2016

Uh oh!

eliasnaur commented May 22, 2016

Uh oh!

eliasnaur commented May 24, 2016

Uh oh!

crawshaw commented May 24, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eliasnaur commented May 24, 2016

Uh oh!

crawshaw commented May 24, 2016

Uh oh!

gopherbot commented May 24, 2016

Uh oh!

eliasnaur commented May 24, 2016

Uh oh!

mwhudson commented May 24, 2016

Uh oh!

eliasnaur commented May 16, 2016 •

edited

Loading

crawshaw commented May 24, 2016 •

edited

Loading