source: trunk/softs/tests_ccvcache_v4/README @ 267

Last change on this file since 267 was 267, checked in by bouyer, 11 years ago

Forced commit to test post-commit-hook

File size: 2.2 KB
Line 
1This is a very basic framework for running regression tests against
2a mips32+ccvcache TSAR platform. Here's the layout of this directory:
3
4../../../platforms/tsarv4_mono_mmu
5        contains the soclib platform description and simulation executable.
6        It should be compiled before starting tests.
7        it uses the vci_simhelper component, used to stop the simulation
8        with an exit value.  The framework uses this exit status
9        (with other things, see below) to determine if a test
10        is successfull. The simulator will exit with a non-0 exit status
11        after 100000 cycles (and a message to stderr), so the tests are
12        expected to be simple.
13        The platform has a tty, which is redirected to a file along with
14        the simlulator's output. The test framework may search for specific
15        strings in this file to determine if a test was successfull.
16common/
17        Some common functions, ldscripts, etc ... used by the tests.
18        It has a subr.S which holds usefull subroutines, such as
19        print() and printx().
20Makefile.inc
21        included from the test's Makefiles. Basic stuff to compile a
22        mips32 ELF executable for a test. It expects a test.S,
23        add the subr.S from common and eventually additionnal object
24        files.
25test_*/
26        these directories holds the test themselves. They have a run
27        script which does what is needed to compile and run a test,
28        print "test failed" or "test passed" on stdout, and clean the
29        directory if it's successfull. A sample script will call
30        make, then run the simulator with srdout/stderr redirected
31        to a file. If the simulator exists with a 0 status, this
32        script search for some strings in the output (that the
33        test program would have printed). This is an additionnal way
34        to check that all worked properly.
35        Tests are written in assembly; as we're testing for very specific
36        conditions (such as an instruction in a branch's delay slot on
37        a page boundary), we don't want the compiler to optimise things
38        or otherwise reorder instructions.
39        If the test was successfull, the 'run' script cleanups the
40        directory. Otherwise the 'run.out' file is available to
41        start looking at what's wrong.
42run_tests
43        runs all the test_*/run scripts - the goal being that
44        all of them print "test passsed" :). Directories are explicitely
45        listed in the run_tests script (order does matter to have a readable
46        output)
47
Note: See TracBrowser for help on using the repository browser.