https://github.com/nepx/verr
Test suite for x86 emulators
https://github.com/nepx/verr
testing-tools x86 x86-assembly
Last synced: 3 months ago
JSON representation
Test suite for x86 emulators
- Host: GitHub
- URL: https://github.com/nepx/verr
- Owner: nepx
- Created: 2020-07-25T16:53:17.000Z (almost 5 years ago)
- Default Branch: master
- Last Pushed: 2021-02-14T00:20:38.000Z (over 4 years ago)
- Last Synced: 2024-12-30T06:17:50.417Z (5 months ago)
- Topics: testing-tools, x86, x86-assembly
- Language: Assembly
- Homepage:
- Size: 27.3 KB
- Stars: 3
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: readme.md
Awesome Lists containing this project
README
# verr: x86 emulator accuracy test
`verr` is a set of small assembly language programs to test x86 emulators. [It's also the name of an instruction](https://www.felixcloutier.com/x86/verr:verw). The tests are based on the official [RISC-V test suite](https://github.com/riscv/riscv-tests), though there are a number of differences.
## Test Layout
Each test is a small self-checking binary file and must be executed in a specific environment called a Test Virtual Machine (TVM). A TVM is an artificially-created environment for a test to run in; look in the various `src/` directories to find out what registers and fields that you have to populate. Those left unspecified do not have to be modified; if a TVM does not specify the initial value of `CR2`, for instance, then the register will either not be touched or be written before it is read.
Because the tests check themselves, the values of the registers or memory do not need to be inspected afterwards. However, this means that instructions that check the results must perform correctly. The CPU emulator can be reused between tests, as long as its fields are reinitialized back to zero, and memory does not need to be cleared.
A byte will be written to port `0x1234` on completion. Zero indicates that the test was successful; other values indicate that something went wrong. Look up the individual test to figure out why. Aside from performance tests, if a test runs more than a few million instructions, it has likely failed. Triple faults always indicate a failure.
## "This test didn't catch *that* bug!"
Of course, since this is the work of one individual, there are sure to be instructions or edge cases that fall between the cracks. Pull requests and issues are gladly accepted.