cmd/compile: bootstrap crashes out with illegal instruction on ppc64

[NattyNarwhal]

Please answer these questions before submitting your issue. Thanks!

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

go version go1.6 linux/amd64 (to start bootstrapping with)

trying to build 1.10

Does this issue reproduce with the latest release?

Trying to build latest stable: 1.10.

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

On local system:

GOARCH="ppc64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/home/calvin/go-ppc64be"
GOTOOLDIR="/home/calvin/go-ppc64be/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -fmessage-length=0"
CXX="g++"
CGO_ENABLED="0"

Remote system: trying to build for Linux/ppc64

What did you do?

calvin@azimuth:~/go/src$ GOROOT_BOOTSTRAP=/usr/lib/go-1.6 ./bootstrap.bash

Copied the created tarball over, then ran the go binary contained within to see if it worked.

What did you expect to see?

The cross-compile starting

What did you see instead?

> gdb --args go-linux-ppc64-bootstrap/bin/go version
GNU gdb (GDB; SUSE Linux Enterprise 11) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "ppc64-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from go-linux-ppc64-bootstrap/bin/go...done.
warning: File "/home/calvin/go-linux-ppc64-bootstrap/src/runtime/runtime-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
        add-auto-load-safe-path /home/calvin/go-linux-ppc64-bootstrap/src/runtime/runtime-gdb.py
line to your configuration file "/home/calvin/.gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/home/calvin/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"
(gdb) run
Starting program: /home/calvin/go-linux-ppc64-bootstrap/bin/go version

Program received signal SIGILL, Illegal instruction.
0x000000000004a05c in runtime.check () at /home/calvin/go-linux-ppc64-bootstrap/src/runtime/runtime1.go:253
253             atomic.Or8(&m[1], 0xf0)
(gdb) x/2i $pc - 4
   0x4a058 <runtime.check+504>: sync
=> 0x4a05c <runtime.check+508>: lbarx   r31,0,r4
(gdb)

[laboger]

Starting with go 1.9, the minimum supported instruction set is power8 for both ppc64 and ppc64le. If you are on power7 or earlier you will get a SIGILL on the lbarx because that is new in power8.

This is documented in https://golang.org/doc/go1.9.

[NattyNarwhal]

Yes, I became aware of this and the associated issue. It seems quite silly on the ppc64 big-endian side, because there's essentially no reason to run big-endian on POWER8.

[andybons]

@NattyNarwhal what is your suggested course of action?

[NattyNarwhal]

I had to roll back to 1.8.7 so it could run on the POWER6 system. It seems silly to me to make ppc64 require POWER8 when everyone on a POWER8 is almost certainly running ppc64le; so I'd be one of the people recommending that ppc64 support older processors.

[andybons]

Thanks for the clarification.

In that case, I would continue the conversation on #19074 and/or write a proposal (golang.org/s/proposal) making a case to support older processors for ppc64.

The issue you are describing is working as intended (at the moment). Your suggested change to support older processors falls outside the scope of this (more specific) report.

Hope this helps.