This page was produced by an automated import process, and may have formatting errors; feel free to fix.
Testsuite Parameters
Several variables exist to modify the behavior of the testsuite.
TRANSCRIPT
Sometimes it is convenient to get a transcript of the commands which the testsuite sends to GDB. For example, if GDB crashes during testing, a transcript can be used to more easily reconstruct the failure when running GDB under GDB.
You can instruct the GDB testsuite to write transcripts by setting the DejaGNU variable TRANSCRIPT (to any value) before invoking runtest or make check. The transcripts will be written into DejaGNU’s output directory. One transcript will be made for each invocation of GDB; they will be named transcript.''n'', where n is an integer. The first line of the transcript file will show how GDB was invoked; each subsequent line is a command sent as input to GDB.
make check RUNTESTFLAGS=TRANSCRIPT=y
Note that the transcript is not always complete. In particular, tests of completion can yield partial command lines.
GDB
Sometimes one wishes to test a different GDB than the one in the build directory. For example, one may wish to run the testsuite on /usr/bin/gdb.
make check RUNTESTFLAGS=GDB=/usr/bin/gdb
GDBSERVER
When testing a different GDB, it is often useful to also test a different gdbserver.
make check RUNTESTFLAGS="GDB=/usr/bin/gdb GDBSERVER=/usr/bin/gdbserver"
INTERNAL_GDBFLAGS
When running the testsuite normally one doesn’t want whatever is in ~/.gdbinit to interfere with the tests, therefore the test harness passes -nx to GDB. One also doesn’t want any windowed version of GDB, e.g., ‘gdb -tui’, to run. This is achieved via INTERNAL_GDBFLAGS.
set INTERNAL_GDBFLAGS "-nw -nx"
This is all well and good, except when testing an installed GDB that has been configured with --with-system-gdbinit. Here one does not want ~/.gdbinit loaded but one may want the system .gdbinit file loaded. This can be achieved by pointing $HOME at a directory without a .gdbinit and by overriding INTERNAL_GDBFLAGS and removing -nx.
cd testsuite HOME=`pwd` runtest \ GDB=/usr/bin/gdb \ GDBSERVER=/usr/bin/gdbserver \ INTERNAL_GDBFLAGS=-nw
GDB_PARALLEL
When testing natively (that is, not with a remote host), the GDB test suite can be run in a fully parallel mode. In this mode, each .exp file can be run separately. The test suite will ensure that all the temporary files created by the test suite do not clash, by putting them into separate directories. This mode is primarily intended for use by the Makefile.
To use this mode, set the GDB_PARALLEL on the runtest command line. Before starting the tests, you must ensure that the directories cache, outputs, and temp in the test suite build directory are either empty or have been deleted. cache in particular is used to share data across invocations of runtest, and files there may affect the test results. Note that the Makefile automatically does these deletions.
GDB_INOTIFY
For debugging parallel mode, it is handy to be able to see when a test case writes to a file outside of its designated output directory.
If you have the ‘inotify-tools’ package installed, you can set the GDB_INOTIFY variable on the runtest command line. This will cause the test suite to watch for parallel-unsafe file creations and report them, both on ‘stdout’ and in the test suite .log file.
This setting is only meaningful in conjunction with GDB_PARALLEL.
There are two ways to run the testsuite and pass additional parameters to DejaGnu. The first is with make check and specifying the makefile variable ‘RUNTESTFLAGS’.
make check RUNTESTFLAGS=TRANSCRIPT=y
The second is to cd to the testsuite directory and invoke the DejaGnu runtest command directly.
cd testsuite make site.exp runtest TRANSCRIPT=y