cmd/link: go 1.16 plugin does not initialize global variables correctly when not used directly

[metalwolf]

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

$ go version
go version go1.16.1 linux/amd64

Does this issue reproduce with the latest release?

yes
It actually appeared with the latest issue, was not happening in older versions ( <= 1.15)

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/home/sites/go/bin"
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/sites/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/sites/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.1"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/sites/webability-go/test/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=/tmp/go-build2426045409=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I have build 2 plugins, using the same import module
The import module file set up a &map[string]*struct{} as a global variable, set by Containers = &map[string]*Container{}
Container can be any random struct
It exists another global variable Others = 123

The first plugin, just make a print of global variable 'Others' without addressing Containers from the import module
The second plugin uses the Containers global variable.

Strangely on this scheme, the second plugin gets a *map[string]*Container as NIL instead of a pointer to the structure.
When the Containers variable is used from the first plugin, anything works correctly and all the global variables are correctly set.

This error appreats in Go 1.16, was not happening in any previous version (tested to work correctly on 1.15 and 1.14)

What did you expect to see?

A correct implementation of the *map[string]*struct , pointing an existing map instead of a NIL of the map

What did you see instead?

a pointer to the NIL of the map instead of the map

I join the gzip of the 6 files environment

On GO 1.15.8:
[root@mexico test]# ./start.sh
213
START PLUG 2: &base.ContainersList{} 0x7fe6cb390b80 0xc000094210

Works correctly, the *Containers contains the pointer to the map

On GO 1.16.1:
[root@mexico test]# ./start.sh
213
START PLUG 2: &base.ContainersList(nil) 0x7f02a2329ca0 0x0

You will note the 0x0 as the NIL pointer of the *base.Containers contents. which is not initialized correctly

Code to reproduce the error:

test.zip

[cherrymui]

The code you attached doesn't include package "base". Could you include that? Thanks.

[metalwolf]

Sorry, my mistake using zip on unix O_o
Correct version is here:

test.zip

[cherrymui]

Thanks. I can reproduce the problem. I think I understand the cause now. Will work on a fix.

[metalwolf]

Thanks. I already have a simple workaround, I just declare the global variable

var Containers map[string]*Container // without assignation

and I assign it into the init() function.

func init() {
Containers = &map[string]*Container{}
}

Works like a charm.

• Phil

[cherrymui]

@gopherbot please backport this to Go 1.16. This is a mis-compilation bug in Go 1.16. Thanks.

[gopherbot]

Change https://golang.org/cl/301793 mentions this issue: cmd/compile, cmd/link: dynamically export writable static tmps

[gopherbot]

Backport issue(s) opened: #45030 (for 1.16).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

[gopherbot]

Change https://golang.org/cl/302449 mentions this issue: [release-branch.go1.16] cmd/compile, cmd/link: dynamically export writable static tmps