[Bug gas/18639] New: Testing of gas by executing the assembled code on the target CPU

[m at rolle dot name]

https://sourceware.org/bugzilla/show_bug.cgi?id=18639

            Bug ID: 18639
           Summary: Testing of gas by executing the assembled code on the
                    target CPU
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: gas
          Assignee: unassigned at sourceware dot org
          Reporter: m at rolle dot name
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.