This page was produced by an automated import process, and may have formatting errors; feel free to fix.
Using the Testsuite
To run the testsuite, simply go to the GDB object directory (or to the testsuite’s objdir) and type make check. This just sets up some environment variables and invokes DejaGNU’s runtest script. While the testsuite is running, you’ll get mentions of which test file is in use, and a mention of any unexpected passes or fails. When the testsuite is finished, you’ll get a summary that looks like this:
=== gdb Summary === # of expected passes 6016 # of unexpected failures 58 # of unexpected successes 5 # of expected failures 183 # of unresolved testcases 3 # of untested testcases 5
To run a specific test script, type:
make check RUNTESTFLAGS='''tests'''
where tests is a list of test script file names, separated by spaces.
If you use GNU make, you can use its -j option to run the testsuite in parallel. This can greatly reduce the amount of time it takes for the testsuite to run. In this case, if you set RUNTESTFLAGS then, by default, the tests will be run serially even under -j. You can override this and force a parallel run by setting the make variable FORCE_PARALLEL to any non-empty value. Note that the parallel make check assumes that you want to run the entire testsuite, so it is not compatible with some dejagnu options, like --directory.
The ideal test run consists of expected passes only; however, reality conspires to keep us from this ideal. Unexpected failures indicate real problems, whether in GDB or in the testsuite. Expected failures are still failures, but ones which have been decided are too hard to deal with at the time; for instance, a test case might work everywhere except on AIX, and there is no prospect of the AIX case being fixed in the near future. Expected failures should not be added lightly, since you may be masking serious bugs in GDB. Unexpected successes are expected fails that are passing for some reason, while unresolved and untested cases often indicate some minor catastrophe, such as the compiler being unable to deal with a test program.
When making any significant change to GDB, you should run the testsuite before and after the change, to confirm that there are no regressions. Note that truly complete testing would require that you run the testsuite with all supported configurations and a variety of compilers; however this is more than really necessary. In many cases testing with a single configuration is sufficient. Other useful options are to test one big-endian (Sparc) and one little-endian (x86) host, a cross config with a builtin simulator (powerpc-eabi, mips-elf), or a 64-bit host (Alpha).
If you add new functionality to GDB, please consider adding tests for it as well; this way future GDB hackers can detect and fix their changes that break the functionality you added. Similarly, if you fix a bug that was not previously reported as a test failure, please add a test case for it. Some cases are extremely difficult to test, such as code that handles host OS failures or bugs in particular versions of compilers, and it’s OK not to try to write tests for all of those.
DejaGNU supports separate build, host, and target machines. However, some GDB test scripts do not work if the build machine and the host machine are not the same. In such an environment, these scripts will give a result of “UNRESOLVED”, like this:
UNRESOLVED: gdb.base/example.exp: This test script does not work on a remote host.