Bug 18639

This is a big project I am suggesting, but I think it is very important.

I just filed bug 18636, in which incorrect code is generated by gas, and this incorrect code will crash on both AMD and Intel CPUs if executed.

So a logical way of catching these earlier in the release cycle would be to take all of the .o files generated by the testsuite (actually, just those that are intended to assemble to correct executing code) and actually link the .o files into a tester executable that will run that code.

As a minimum, it should just ensure that the program does not crash.

Of course, the object code needs to be arranged in a way that can be run from beginning to end.  Perhaps the tester could include the source file between an entry declaration and a ret instruction, so that it could be conveniently called.

The object code could also contain valid instructions which would actually crash due to invalid (e.g. misaligned addresses) values, so these cases would need to
be either adjusted or removed from an executable test version of the program.

A more ambitious project would be to test individual instructions by setting inputs and checking outputs.  This would catch cases where gas produces code that executes without a crash but is actually the wrong instruction.  A simple example could be the immediate byte used as an opcode extension.  If the wrong value is generated, then the instruction will perform a different operation than was intended.

Generation of these tests might be partly automated by going through the instruction tables, using a _different_ assembler (such as MASM) to produce the binary encoding, then capturing outputs for various inputs.  These would form a table for testing gas generated code for the same instructions.