New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/build: validate 387 binaries somehow #13946

Open
bradfitz opened this Issue Jan 14, 2016 · 5 comments

Comments

Projects
None yet
4 participants
@bradfitz
Member

bradfitz commented Jan 14, 2016

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.

@bradfitz bradfitz added the Builders label Jan 14, 2016

@bradfitz bradfitz added this to the Unreleased milestone Jan 14, 2016

@randall77

This comment has been minimized.

Contributor

randall77 commented Jan 14, 2016

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

This comment has been minimized.

Contributor

davecheney commented Jan 14, 2016

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 notifications@github.com
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

This comment has been minimized.

Member

bradfitz commented Jan 14, 2016

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

@rsc

This comment has been minimized.

Contributor

rsc commented Jan 14, 2016

@davecheney

This comment has been minimized.

Contributor

davecheney commented Jan 14, 2016

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 <notifications@github.com

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment