possible non-387 instructions in a GO386=387 build

[sbinet]

hi,

I tried to cross-compile this simple program:

package main
func main() { println("hello") }

from a linux-64b host to a PC/104 target.
I had rebuilt the go-1.5.1 from sources, exporting GO386=387.

running on the host:

$ go build -o hello-1.5 ./hello.go

and then copying on the target, running under gdb, I get:

$ gdb ./hello-1.5
(gdb) r
Starting program: /root/hello-1.5

Program received signal SIGILL, Illegal instruction.
runtime.prefetcht0 () at /root/dev/go/src/runtime/asm_386.s:1669
warning: Source file is more recent than executable.
1669 PREFETCHT0 (AX)
(gdb) bt
#0  runtime.prefetcht0 () at /root/dev/go/src/runtime/asm_386.s:1669
#1  0x0807370e in runtime.testAtomic64 () at /root/dev/go/src/runtime/runtime1.go:98
#2  0x08073ef5 in runtime.check () at /root/dev/go/src/runtime/runtime1.go:290
#3  0x08088fba in runtime.rt0_go () at /root/dev/go/src/runtime/asm_386.s:105
#4  0x00000000 in ?? ()
(gdb) lis
1664 // traceback from goexit1 must hit code range of goexit
1665 BYTE $0x90 // NOP
1666
1667 TEXT runtime·prefetcht0(SB),NOSPLIT,$0-4
1668 MOVL addr+0(FP), AX
1669 PREFETCHT0 (AX)
1670 RET
1671
1672 TEXT runtime·prefetcht1(SB),NOSPLIT,$0-4
1673 MOVL addr+0(FP), AX

doing the same dance with go-1.4.3, I get instead:

$ gdb ./hello-1.4
(gdb) r
Starting program: /root/hello-1.4

Program received signal SIGILL, Illegal instruction.
runtime.atomicload64 () at /root/go1.4/src/runtime/asm_386.s:575
575 BYTE $0x0f; BYTE $0x6f; BYTE $0x00
(gdb) bt
#0  runtime.atomicload64 () at /root/go1.4/src/runtime/asm_386.s:575
#1  0x080cd15c in TestAtomic64 () at /root/go1.4/src/runtime/runtime.c:158
#2  0x080cd5d7 in runtime.check () at /root/go1.4/src/runtime/runtime.c:263
#3  0x080badbb in runtime.rt0_go () at /root/go1.4/src/runtime/asm_386.s:91
#4  0x00000000 in ?? ()
(gdb) lis
570 // uint64 atomicload64(uint64 volatile* addr);
571 TEXT runtime·atomicload64(SB), NOSPLIT, $0-12
572 MOVL ptr+0(FP), AX
573 LEAL ret_lo+4(FP), BX
574 // MOVQ (%EAX), %MM0
575 BYTE $0x0f; BYTE $0x6f; BYTE $0x00
576 // MOVQ %MM0, 0(%EBX)
577 BYTE $0x0f; BYTE $0x7f; BYTE $0x03
578 // EMMS
579 BYTE $0x0F; BYTE $0x77

Taru Karttunen on golang-nuts says:

The issue is the 64bit atomics using MMX. If they are 64-bit aligned
then using FISTP/FILD instead when GO386=387 should probably fix this.

additional informations:

the linux 64b host is running the latest archlinux.
the pc/104 target is running a debian-8.2 (jessie):

$ uname -a
Linux pc104box 3.16.0-4-586 #1 Debian 3.16.7-ckt11-1+deb8u5
(2015-10-09) i586 GNU/Linux

$ cat /proc/cpuinfo | grep flags
flags : fpu tsc cx8

here are the complete specs for my pc/104 box:
http://pc104.org/hardware-specifications/pc104/

[bradfitz]

For what it's worth, we have a linux-386-387 builder, but it's running on Haswell, so we don't actually trap on MMX, etc. It's mostly there to catch that the resulting code still compiles & runs.

Perhaps we can add a binary verifier step to that builder, scanning for bogus instructions, ala the Nacl verifier? We don't support/require self-modifying code anymore, so maybe it's actually verifiable? @minux, @randall77, ... ?

[randall77]

GO386=387: use x87 for floating point operations; should support all x86 chips (Pentium MMX or later).

I don't think we support non-MMX chips. We could probably drop prefetching from 386, but we still need atomic 64-bit loads. How would you propose to do them?

[minux]

We don't support 32-bit x86 hosts before Pentium MMX as we do require 64-bit atomics. This is documented at https://golang.org/doc/install/source: GO386=387: use x87 for floating point operations; should support all x86 chips (Pentium MMX or later).

[bradfitz]

Maybe we can detect that at start-up in the runtime and fail early with a useful error message.

[randall77]

We do detect it at startup, that's what the traces above show. We fail with an "illegal instruction" trap. It's not quite "Go do not support this processor because it is missing MMX instructions" but people playing with pre-MMX chips aren't neophytes - they should know what that error means.

[minux]

I did some benchmarks with the Go 1 benchmark, and it seems the manual prefetching doesn't give any better result on a modern processor. I suggest that we disable the prefetching on 386 and add an explicit test for MMX. (We should also benchmark to see whether prefetching helps amd64 or not)

[gopherbot]

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

[gopherbot]

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

[jeffallen]

I really like minux's proposal because i really hate leaving older x86 embedded systems without go support.