x/build: validate 387 binaries somehow

[bradfitz]

We should run a builder that somehow validates our GO386=387 builder, making sure we never generated prohibited instructions. (per comment by @randall77 in #13923)

We seem to occasionally regress.

How to validate?

• qemu? Slow?
• use some toolexec binary that validates the binaries using the disassembler?
• actually use an old MMX-only processor somewhere. which?

/cc @minux @randall77 @ianlancetaylor @rsc for opininions.

[randall77]

I'd be happy if we just qemu'd a "hello world" binary to completion. That shouldn't be too slow. It would catch most of the cases. We could add a few map operations, a channel select, etc. for good measure.

Can you configure qemu to faithfully emulate a Pentium MMX, missing instruction faults and all?

Just validating using the disassembler doesn't quite work, as we have non-MMX code guarded by CPUID checks. Those cases may be few enough in number that we could explicitly suppress errors in those functions.

[davecheney]

I'd like to propose a counter proposal -- demote 387 to a non first class
build, in the same manner we've done goarm=5 and older versions of darwin.
We'll fix them if we can when bugs are reported, but they aren't part of
the build bot testing matrix.

On Thu, Jan 14, 2016 at 11:42 AM, Keith Randall [email protected]
wrote:

I'd be happy if we just qemu'd a "hello world" binary to completion. That
shouldn't be too slow. It would catch most of the cases. We could add a few
map operations, a channel select, etc. for good measure.

Can you configure qemu to faithfully emulate a Pentium MMX, missing
instruction faults and all?

Just validating using the disassembler doesn't quite work, as we have
non-MMX code guarded by CPUID checks. Those cases may be few enough in
number that we could explicitly suppress errors in those functions.

—
Reply to this email directly or view it on GitHub
#13946 (comment).

[bradfitz]

@davecheney, but we kinda have an GOARM=5 builder at least (admittedly on ARMier hardware than ARM=5), which catches some stuff.

[rsc]

I think we have too many builders, and I'm skeptical we need one for this. We can make the 386 build test that cmd/go (which imports basically everything) doesn't have any instructions it should not.

[davecheney]

Yes, sorry I want not precise enough. My suggestion isn't a direct analog
of the GOARM=5 situation, or the old darwin version scenario. Our GOARM=5
builder does catch some things, certainly when the soft fp code is broken,
but it won't catch the major limitation of arm5, no support for unaligned
accesses. Similarly, we have a GO386=387 builder, which will check that the
older code generation is sane, but won't stop us from accidentally
referencing an old 387 instruction.

The problem that cropped up apparently was introduced in 1.1 and took until
now for someone to hit. My suggestion is, given the difficulty in testing
these older platforms, and the fact that nobody is making them any more,
not to expend extra effort above what we have so far.

On Thu, Jan 14, 2016 at 11:51 AM, Brad Fitzpatrick <[email protected]

wrote:

@davecheney https://github.com/davecheney, but we kinda have an GOARM=5
builder at least (admittedly on ARMier hardware than ARM=5), which catches
some stuff.

—
Reply to this email directly or view it on GitHub
#13946 (comment).

[dmitshur]

Support for GO386=387 was dropped in Go 1.16 (https://go.dev/doc/go1.16#386).
There's a linux-386-softfloat builder that tests with GO386=softfloat.