This page was produced by an automated import process, and may have formatting errors; feel free to fix.
The testsuite is entirely contained in gdb/testsuite. While the testsuite includes some makefiles and configury, these are very minimal, and used for little besides cleaning up, since the tests themselves handle the compilation of the programs that GDB will run. The file testsuite/lib/gdb.exp contains common utility procs useful for all GDB tests, while the directory testsuite/config contains configuration-specific files, typically used for special-purpose definitions of procs like gdb_load and gdb_start.
The tests themselves are to be found in testsuite/gdb.* and subdirectories of those. The names of the test files must always end with .exp. DejaGNU collects the test files by wildcarding in the test directories, so both subdirectories and individual files get chosen and run in alphabetical order.
The following table lists the main types of subdirectories and what they are for. Since DejaGNU finds test files no matter where they are located, and since each test file sets up its own compilation and execution environment, this organization is simply for convenience and intelligibility.
This is the base testsuite. The tests in it should apply to all configurations of GDB (but generic native-only tests may live here). The test programs should be in the subset of C that is valid K&R, ANSI/ISO, and C++ (#ifdefs are allowed if necessary, for instance for prototypes).
Language-specific tests for any language lang besides C. Examples are gdb.cp and gdb.java.
Non-portable tests. The tests are specific to a specific configuration (host or target), such as HP-UX or eCos. Example is gdb.hp, for HP-UX.
Tests specific to a particular compiler. As of this writing (June 1999), there aren’t currently any groups of tests in this category that couldn’t just as sensibly be made platform-specific, but one could imagine a gdb.gcc, for tests of GDB’s handling of GCC extensions.
Tests that exercise a specific GDB subsystem in more depth. For instance, gdb.disasm exercises various disassemblers, while gdb.stabs tests pathways through the stabs symbol reader.