cmd/compile: relocation error when building some programs on linux/amd64 after dev.regabi merge

[siebenmann]

What version of Go are you using (go version)?

$ go version
go version devel +2f0da6d9e2 Wed Feb 17 01:29:54 2021 +0000 linux/amd64

This is the current git tip, but the problem happens from commit 8482559 onward (which merges the dev.regabi branch into main).

Does this issue reproduce with the latest release?

No.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/homes/hawklords/cks/.cache/go-build"
GOENV="/homes/hawklords/cks/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/homes/hawklords/cks/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/homes/hawklords/cks/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/data/code/go-lang/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/data/code/go-lang/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel +2f0da6d9e2 Wed Feb 17 01:29:54 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/homes/hawklords/cks/go/src/github.com/monsterxx03/gospy/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmpfs/go-build1010952997=/tmp/go-build -gno-record-gcc-switches"

What did you do?

The simplest reproduction is:

cd /tmp
git clone https://github.com/monsterxx03/gospy
cd gospy
go build

(Unfortunately the program doesn't build as a module build with 'go install' due to a 'replace' directive in its go.mod.)

What did you expect to see?

The build works.

What did you see instead?

# github.com/monsterxx03/gospy
github.com/monsterxx03/gospy/pkg/term.NewTerm.func1·f: relocation target github.com/monsterxx03/gospy/pkg/term.NewTerm.func1 not defined

[bcmills]

CC @cherrymui @jeremyfaller

[thanm]

Looks like a missing closure -- could this have something to do with the recent changes to the order of closure processing in walk? @mdempsky

[mdempsky]

Yeah, that seems plausibly related to the change in closure processing.

I don't immediately see any function literals in NewTerm in https://github.com/monsterxx03/gospy/blob/master/pkg/term/term.go though, so I'm not sure where NewTerm.func1 is coming from.

I vaguely remember having to deal with some more of these .f issues on dev.typeparams. It would be worthwhile to check if the issue still reproduces on that branch (also, testing both with -gcflags=all=-G=3 and without).

Otherwise, minimizing down the failure case would be helpful.

[cuonglm]

@mdempsky I bet this issue is the same as many other issues opened recently, which related to inlining of OCLOSURE. If you build the repo with go build -gcflags=all=-l, then it's compiled ok.

[cuonglm]

@mdempsky also, FYI, go build -gcflags=all=-G=3 works!

[siebenmann]

Here is a more minimal reproduction that still requires a second package, along with a theory about what field is involved.

package main

import "github.com/gizak/termui/v3/widgets"

// widgets.Table contains a 'ColumnResizer func()' field that is
// initialized in NewTable() to a 'func() {}'. However, I don't see
// the issue if I duplicate that within a single package, here.
type Term struct {
	top *widgets.Table
}

func NewFred() *Term {
	table := widgets.NewTable()
	return &Term{top: table}
}

func main() {
	NewFred()
}

Building this with git tip produces main.main.func1·f: relocation target main.main.func1 not defined. Both -gcflags= settings above produced a successful build.

[siebenmann]

Unsurprisingly this has stopped happening after the just landed commit 8027343, "disable inlining functions with closures for now". That was done for bug #44370, so possibly the fix for it will also fix this issue.

[tosi3k]

FYI: this stopped working, most probably after https://go-review.googlesource.com/c/go/+/296649/ got merged.

[siebenmann]

I can confirm that git tip from commit 9a555fc onward now has this issue again; building either gospy or my test example now fails again.

[mdempsky]

(I thought @danscales had been CC'd on this issue already, but it looks like he has not.)