cmd/link: reject >2GB static data

[randall77]

The following code prints 2!

package main
var a[1<<31]byte
func main() {
     println(a[0])
}

It seems that when bss is big, bad things happen on darwin. At 1<<30, it works (prints 0). It also fails at 1<<31, 1<<32, 1<<33. We get a compile error at 1<<31 - 1:

runtime.mallocinit: non-pc-relative relocation address is too big: 0x80070dbf

We should fail instead of silently generating bad code.

Linux works correctly: succeeds for up to close to 1<<32, fails with the above error for larger sizes.

[minux]

Are you sure Linux can handle that code?

On my linux/amd64 system, it also prints 2.

$ cat issue9862.go 
package main
var a [1 << 31]byte
func main() {
        println(a[0])
}
$ go version
go version devel +a809dc7 Sat Feb 14 01:01:19 2015 +0000 linux/amd64
$ go build issue9862.go
$ ./issue9862
2
$ size ./issue9862
   text    data     bss     dec     hex filename
 673232    2466  191856  867554   d3ce2 issue9862

In general, our toolchain can't handle static data (or text, for that matter)
bigger than 2GB.

[randall77]

You're right, on my linux/amd64 system at tip it prints 2. Turns out I was in the wrong directory and tested go 1.2.1. Go 1.2.1 generates the correctly sized bss, at least.

[minux]

I've experimented with various released version of Go:

$ go1 build a.go 
# command-line-arguments
./a.go:3: array bound must be non-negative
$ go112 build a.go 
$ size a
   text    data     bss     dec     hex filename
 264114   12368 2147557304      2147833786      800557ba        a
$ ./a
0
$ go121 build a.go
$ size a
   text    data     bss     dec     hex filename
 342097   18072 2147603800      2147963969      80075441        a
$ ./a
0
$ go133 build a.go
$ size a
   text    data     bss     dec     hex filename
 318996   16656  118920  454572   6efac a
$ ./a
2
$ go141 build a.go 
$ size a
   text    data     bss     dec     hex filename
 404626   12968  100392  517986   7e762 a
$ ./a
0

It's broken since Go 1.3.

[josharian]

Possibly related: #7980

[gopherbot]

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