This is a collection of tests for GDB. The file gdb/README contains basic instructions on how to run the testsuite, while this file documents additional options and controls that are available. The GDB wiki may also have some pages with ideas and suggestions. Running the Testsuite ********************* There are two ways to run the testsuite and pass additional parameters to DejaGnu. The first is to do `make check' in the main build directory and specifying the makefile variable `RUNTESTFLAGS': make check RUNTESTFLAGS='GDB=/usr/bin/gdb gdb.base/a2-run.exp' The second is to cd to the testsuite directory and invoke the DejaGnu `runtest' command directly. cd testsuite make site.exp runtest GDB=/usr/bin/gdb (The `site.exp' file contains a handful of useful variables like host and target triplets, and pathnames.) Parallel testing **************** If not testing with a remote host (in DejaGnu's sense), you can run the GDB test suite in a fully parallel mode. In this mode, each .exp file runs separately and maybe simultaneously. The test suite ensures 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. For GNU make, the Makefile tries to run the tests in parallel mode if any -j option is given. For a non-GNU make, tests are not parallelized. If RUNTESTFLAGS is not empty, then by default the tests are serialized. This can be overridden by either using the `check-parallel' target in the Makefile, or by setting FORCE_PARALLEL to any non-empty value: make check-parallel RUNTESTFLAGS="--target_board=native-gdbserver" make check RUNTESTFLAGS="--target_board=native-gdbserver" FORCE_PARALLEL=1 If you want to use runtest directly instead of using the Makefile, see the description of GDB_PARALLEL below. Racy testcases ************** Sometimes, new testcases are added to the testsuite that are not entirely deterministic, and can randomly pass or fail. We call them "racy testcases", and they can be bothersome when one is comparing different testsuite runs. In order to help identifying them, it is possible to run the tests several times in a row and ask the testsuite machinery to analyze the results. To do that, you need to specify the RACY_ITER environment variable to make: make check RACY_ITER=5 -j4 The value assigned to RACY_ITER represents the number of times you wish to run the tests in sequence (in the example above, the entire testsuite will be executed 5 times in a row, in parallel). It is also possible to check just a specific test: make check TESTS='gdb.base/default.exp' RACY_ITER=3 One can also decide to call the Makefile rules by hand inside the gdb/testsuite directory, e.g.: make check-parallel-racy -j4 In which case the value of the DEFAULT_RACY_ITER variable (inside gdb/testsuite/Makefile.in) will be used to determine how many iterations will be run. After running the tests, you shall see a file name 'racy.sum' in the gdb/testsuite directory. You can also inspect the generated *.log and *.sum files by looking into the gdb/testsuite/racy_ouputs directory. If you already have *.sum files generated from previous testsuite runs and you would like to analyze them without having to run the testsuite again, you can also use the 'analyze-racy-logs.py' script directly. It is located in the gdb/testsuite/ directory, and it expects a list of two or more *.sum files to be provided as its argument. For example: ./gdb/testsuite/analyze-racy-logs.py testsuite-01/gdb.sum \ testsuite-02/gdb.sum testsuite-03/gdb.sum The script will output its analysis report to the standard output. Re-running Tests Outside The Testsuite ************************************** When running a test, the arguments used to run GDB are saved to gdb.cmd and all commands sent to GDB are saved to gdb.in. As well as being a reference of the commands run, they can be used to manually re-run a test by using the gdb.in file as a batch file to a GDB launched with the arguments in the gdb.cmd file, for example: $(cat outputs/gdb.base/store/gdb.cmd) -x outputs/gdb.base/store/gdb.in Tests that run GDB multiple times will append .1, .2, .3 etc to the end of each .cmd and .in file. When gdbserver is launched as part of a test, a gdbserver.cmd will be created. To re-run these tests, run the contents of gdbserver.cmd in a separate terminal before running gdb, for example: $(cat outputs/gdb.base/store/gdbserver.cmd) Alternatively, if the test is run with GDBSERVER_DEBUG="replay", then this will create a gdbserver.replay file which can be used with the gdbreplay tool, instead of launching gdbserver. Running the Performance Tests ***************************** GDB Testsuite includes performance test cases, which are not run together with other test cases, because performance test cases are slow and need a quiet system. There are two ways to run the performance test cases. The first is to do `make check-perf' in the main build directory: make check-perf RUNTESTFLAGS="solib.exp SOLIB_COUNT=8" The second is to cd to the testsuite directory and invoke the DejaGnu `runtest' command directly. cd testsuite make site.exp runtest GDB_PERFTEST_MODE=both GDB_PERFTEST_TIMEOUT=4000 --directory=gdb.perf solib.exp SOLIB_COUNT=8 Only "compile", "run" and "both" are valid to GDB_PERFTEST_MODE. They stand for "compile tests only", "run tests only", and "compile and run tests" respectively. "both" is the default. GDB_PERFTEST_TIMEOUT specify the timeout, which is 3000 in default. The result of performance test is appended in `testsuite/perftest.log'. Testsuite Parameters ******************** The following parameters are DejaGNU variables that you can set to affect the testsuite run globally. GDB By default, the testsuite exercises the GDB in the build directory, but you can set GDB to be a pathname to a different version. For instance, make check RUNTESTFLAGS=GDB=/usr/bin/gdb runs the testsuite on the GDB in /usr/bin. GDBSERVER You can set GDBSERVER to be a particular GDBserver of interest, so for instance make check RUNTESTFLAGS="GDB=/usr/bin/gdb GDBSERVER=/usr/bin/gdbserver" checks both the installed GDB and GDBserver. GDB_DATA_DIRECTORY If you set GDB, then by default the testsuite assumes you are exercising an installed GDB, and thus the testsuite lets GDB use its configured data directory. Otherwise, if you don't set GDB, then by default the tested GDB uses the data directory found under the GDB build directory. You can override this by setting GDB_DATA_DIRECTORY. For instance: make check \ RUNTESTFLAGS="GDB=/path/to/other/build/gdb \ GDB_DATA_DIRECTORY=/path/to/other/build/gdb/data-directory" INTERNAL_GDBFLAGS Command line options passed to all GDB invocations. The default is set in lib/gdb.exp. This is actually considered an internal variable, and you won't normally want to change it. However, in some situations, this may be tweaked as a last resort if the testsuite doesn't have direct support for the specifics of your environment. The testsuite does not override a value provided by the user. As an example, when testing an installed GDB that has been configured with `--with-system-gdbinit', like by default, you do not want ~/.gdbinit to interfere with tests, but, you may want the system .gdbinit file loaded. As there's no way to ask the testsuite, or GDB, to load the system gdbinit but not ~/.gdbinit, a workaround is then to remove `-nx' from INTERNAL_GDBFLAGS, and point $HOME at a directory without a .gdbinit. For example: cd testsuite HOME=`pwd` runtest \ GDB=/usr/bin/gdb \ GDBSERVER=/usr/bin/gdbserver \ INTERNAL_GDBFLAGS="-nw -iex 'set height 0' -iex 'set width 0'" Note that we do not need to specify '-data-directory' here as we are testing an installed GDB. GDB_PARALLEL To use parallel testing mode without using the Makefile, set GDB_PARALLEL on the runtest command line to "yes". 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. The Makefile automatically does these deletions. FORCE_PARALLEL Setting FORCE_PARALLEL to any non-empty value forces parallel testing mode even if RUNTESTFLAGS is not empty. FORCE_SEPARATE_MI_TTY Setting FORCE_MI_SEPARATE_UI to 1 forces all MI testing to start GDB in console mode, with MI running on a separate TTY, on a secondary UI started with "new-ui". 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 to stdout and in the test suite log file. This setting is only meaningful in conjunction with GDB_PARALLEL. TESTS This variable is used to specify which set of tests to run. It is passed to make (not runtest) and its contents are a space separated list of tests to run. If using GNU make then the contents are wildcard-expanded using GNU make's $(wildcard) function. Test paths must be fully specified, relative to the "testsuite" subdirectory. This allows one to run all tests in a subdirectory by passing "gdb.subdir/*.exp", or more simply by using the check-gdb.subdir target in the Makefile. If for some strange reason one wanted to run all tests that begin with the letter "d" that is also possible: TESTS="*/d*.exp". Do not write */*.exp to specify all tests (assuming all tests are only nested one level deep, which is not necessarily true). This will pick up .exp files in ancillary directories like "lib" and "config". Instead write gdb.*/*.exp. Example: make -j10 check TESTS="gdb.server/[s-w]*.exp */x*.exp" If not using GNU make then the value is passed directly to runtest. If not specified, all tests are run. READ1 This make (not runtest) variable is used to specify whether the testsuite preloads the read1.so library into expect. Any non-empty value means true. See "Race detection" below. GDB_TEST_SOCKETHOST This variable can provide the hostname/address that should be used when performing GDBserver-related tests. This is useful in some situations, e.g., when you want to test the IPv6 connectivity of GDB and GDBserver, or when using a different hostname/address is needed. For example, to make GDB and GDBserver use IPv6-only connections, you can do: make check TESTS="gdb.server/*.exp" RUNTESTFLAGS='GDB_TEST_SOCKETHOST=tcp6:[::1]' Note that only a hostname/address can be provided, without a port number. TS This variable turns on the timestamp printing for each line of "make check". Note that the timestamp will be printed on stdout output only. In other words, there will be no timestamp output on either gdb.sum and gdb.log files. If you would like to enable timestamp printing, you can do: make check TS=1 TS_FORMAT You can provide a custom format for timestamp printing with this variable. The format must be a string compatible with "strftime". This variable is only useful when the TS variable is also provided. If you would like to change the output format of the timestamp, you can do: make check TS=1 TS_FORMAT='[%b %H:%S]' GDB_DEBUG When set gdb debug is sent to the file gdb.debug in the test output directory. It should be set to a comma separated list of gdb debug components. For example, to turn on debugging for infrun and target, you can do: make check GDB_DEBUG="infrun,target" GDBSERVER_DEBUG When set gdbserver debug is sent to the a file in the test output directory. It should be set to a comma separated list of the following options: debug - write gdbserver debug to gdbserver.debug. remote - write gdbserver remote debug to gdbserver.debug. replay - write a replay log to the file gdbserver.replay for use with gdbreplay. Alternatively, it can be set to "all" to turn on all the above For example, to turn on gdbserver debugging, you can do: make check GDBSERVER_DEBUG="debug,replay" Architecture-specific Parameters ****************************** This section documents architecture-specific parameters that can be used with the GDB testsuite. - AArch64 (Linux) ARM_CC_FOR_TARGET The AArch64 ports of GDB and GDBserver support debugging AArch32 32-bit programs running on 64-bit state. There are some tests under gdb.multi/ that exercise this particular feature. By default, the testsuite tries to find a compiler capable of generating 32-bit executables. If no compiler is found, or if the 32-bit executable generated by the found compiler can't be executed correctly, the tests will be marked UNSUPPORTED. The list of 32-bit Arm compiler names the testsuite will try can be found in gdb/testsuite/lib/gdb.exp:arm_cc_for_target. You can set ARM_CC_FOR_TARGET to override the search and explicitly specify the compiler to use. This variable should contain the command line for the compiler, including the full path to it, if the compiler is not in $PATH. Example: make check-gdb TESTS="gdb.multi/multi-arch.exp" RUNTESTFLAGS="ARM_CC_FOR_TARGET=arm-linux-gnueabihf-gcc" Race detection ************** The testsuite includes a mechanism that helps detect test races. For example, say the program running under expect outputs "abcd", and a test does something like this: expect { "a.*c" { } "b" { } "a" { } } Which case happens to match depends on what expect manages to read into its internal buffer in one go. If it manages to read three bytes or more, then the first case matches. If it manages to read two bytes, then the second case matches. If it manages to read only one byte, then the third case matches. To help detect these cases, the race detection mechanism preloads a library into expect that forces the `read' system call to always return at most 1 byte. To enable this, either pass a non-empty value in the READ1 make variable, or use the check-read1 make target instead of check. Example: make -j10 check-read1 TESTS="*/paginate-*.exp" If you've already built the read1 support code, either via a previous 'check-read1' run, or by using "make read1", you can use: make -j10 check READ1="1" Note: While the intention is to detect races and make otherwise passing tests fail, it can also have the effect of making otherwise failing tests pass. This happens f.i. if the test is trying to match a gdb prompt using an end of input marker "${gdb_prompt} $" and there is output after the gdb prompt. This may either pass or fail in normal operation, but using check-read1 will ensure that it passes. Use check-readmore to detect this type of failure. Testsuite Configuration *********************** It is possible to adjust the behavior of the testsuite by defining the global variables listed below, either in a `site.exp' file, or in a board file. gdb_test_timeout Defining this variable changes the default timeout duration used during communication with GDB. More specifically, the global variable used during testing is `timeout', but this variable gets reset to `gdb_test_timeout' at the beginning of each testcase, which ensures that any local change to `timeout' in a testcase does not affect subsequent testcases. This global variable comes in handy when the debugger is slower than normal due to the testing environment, triggering unexpected `TIMEOUT' test failures. Examples include when testing on a remote machine, or against a system where communications are slow. If not specifically defined, this variable gets automatically defined to the same value as `timeout' during the testsuite initialization. The default value of the timeout is defined in the file `testsuite/config/unix.exp' (at least for Unix hosts; board files may have their own values). gdb_reverse_timeout Defining this variable changes the default timeout duration when tests under gdb.reverse directory are running. Process record and reverse debugging is so slow that its tests have unexpected `TIMEOUT' test failures. This global variable is useful to bump up the value of `timeout' for gdb.reverse tests and doesn't cause any delay where actual failures happen in the rest of the testsuite. Board Settings ************** DejaGNU includes the concept of a "board file", which specifies testing details for a particular target (which are often bare circuit boards, thus the name). In the GDB testsuite specifically, the board file may include a number of "board settings" that test cases may check before deciding whether to exercise a particular feature. For instance, a board lacking any I/O devices, or perhaps simply having its I/O devices not wired up, should set `noinferiorio'. Here are the supported board settings: gdb,cannot_call_functions The board does not support inferior call, that is, invoking inferior functions in GDB. gdb,can_reverse The board supports reverse execution. gdb,no_hardware_watchpoints The board does not support hardware watchpoints. gdb,nofileio GDB is unable to intercept target file operations in remote and perform them on the host. gdb,noinferiorio The board is unable to provide I/O capability to the inferior. gdb,noresults A program will not return an exit code or result code (or the value of the result is undefined, and should not be looked at). gdb,nosignals The board does not support signals. gdb,skip_huge_test Skip time-consuming tests on the board with slow connection. gdb,skip_float_tests Skip tests related to floating point. gdb,use_precord The board supports process record. gdb_init_command gdb_init_commands Commands to send to GDB every time a program is about to be run. The first of these settings defines a single command as a string. The second defines a TCL list of commands being a string each. The commands are sent one by one in a sequence, first from `gdb_init_command', if any, followed by individual commands from `gdb_init_command', if any, in this list's order. gdb_server_prog The location of GDBserver. If GDBserver somewhere other than its default location is used in test, specify the location of GDBserver in this variable. The location is a file name for GDBserver, and may be either absolute or relative to the testsuite subdirectory of the build directory. in_proc_agent The location of the in-process agent (used for fast tracepoints and other special tests). If the in-process agent of interest is anywhere other than its default location, set this variable. The location is a filename, and may be either absolute or relative to the testsuite subdirectory of the build directory. noargs GDB does not support argument passing for inferior. no_long_long The board does not support type long long. use_cygmon The board is running the monitor Cygmon. use_gdb_stub The tests are running with a GDB stub. exit_is_reliable Set to true if GDB can assume that letting the program run to end reliably results in program exits being reported as such, as opposed to, e.g., the program ending in an infinite loop or the board crashing/resetting. If not set, this defaults to $use_gdb_stub. In other words, native targets are assumed reliable by default, and remote stubs assumed unreliable. gdb,predefined_tsv The predefined trace state variables the board has. gdb,no_thread_names The target doesn't support thread names. gdb,pie_flag The flag required to force the compiler to produce position-independent executables. gdb,pie_ldflag The flag required to force the linker to produce position-independent executables. gdb,nopie_flag The flag required to force the compiler to produce non-position-independent executables. gdb,nopie_ldflag The flag required to force the linker to produce non-position-independent executables. gdb,debug When set gdb debug is sent to the file gdb.debug in the test output directory. It should be set to a comma separated list of gdb debug components. For example, to turn on debugging for infrun and target, set to "infrun,target". gdbserver,debug When set gdbserver debug is sent to the file gdbserver.debug in the test output directory. For valid values see the entry for GDBSERVER_DEBUG. Testsuite Organization ********************** The testsuite is entirely contained in `gdb/testsuite'. The main directory of the testsuite includes some makefiles and configury, but these are 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 directories named '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 typically get chosen and run in alphabetical order. The following lists some notable 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. gdb.base 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 both valid ANSI/ISO C, and C++. gdb. Language-specific tests for any language besides C. Examples are gdb.cp for C++ and gdb.rust for Rust. gdb. Non-portable tests. The tests are specific to a specific configuration (host or target), such as eCos. gdb.arch Architecture-specific tests that are (usually) cross-platform. gdb. 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. gdb.perf GDB performance tests. Writing Tests ************* In many areas, the GDB tests are already quite comprehensive; you should be able to copy existing tests to handle new cases. Be aware that older tests may use obsolete practices but have not yet been updated. You should try to use `gdb_test' whenever possible, since it includes cases to handle all the unexpected errors that might happen. However, it doesn't cost anything to add new test procedures; for instance, gdb.base/exprs.exp defines a `test_expr' that calls `gdb_test' multiple times. Only use `send_gdb' and `gdb_expect' when absolutely necessary. Even if GDB has several valid responses to a command, you can use `gdb_test_multiple'. Like `gdb_test', `gdb_test_multiple' recognizes internal errors and unexpected prompts. Do not write tests which expect a literal tab character from GDB. On some operating systems (e.g. OpenBSD) the TTY layer expands tabs to spaces, so by the time GDB's output reaches `expect' the tab is gone. The source language programs do *not* need to be in a consistent style. Since GDB is used to debug programs written in many different styles, it's worth having a mix of styles in the testsuite; for instance, some GDB bugs involving the display of source lines might never manifest themselves if the test programs used GNU coding style uniformly. Some testcase results need more detailed explanation: KFAIL Use KFAIL for known problem of GDB itself. You must specify the GDB bug report number, as in these sample tests: kfail "gdb/13392" "continue to marker 2" or setup_kfail gdb/13392 "*-*-*" kfail "continue to marker 2" XFAIL Short for "expected failure", this indicates a known problem with the environment. This could include limitations of the operating system, compiler version, and other components. This example from gdb.base/attach-pie-misread.exp is a sanity check for the target environment: # On x86_64 it is commonly about 4MB. if {$stub_size > 25000000} { xfail "stub size $stub_size is too large" return } You should provide bug report number for the failing component of the environment, if such bug report is available, as with this example referring to a GCC problem: if {[test_compiler_info {gcc-[0-3]-*}] || [test_compiler_info {gcc-4-[0-5]-*}]} { setup_xfail "gcc/46955" *-*-* } gdb_test "python print ttype.template_argument(2)" "&C::c" Note that it is also acceptable, and often preferable, to avoid running the test at all. This is the better option if the limitation is intrinsic to the environment, rather than a bug expected to be fixed in the near future. Local vs Remote vs Native ************************* It's unfortunately easy to get confused in the testsuite about what's native and what's not, what's remote and what's not. The confusion is caused by the overlap in vocabulary between DejaGnu and GDB. From a DejaGnu point of view: - native: the host or target board is considered native if the its triplet is the same as the build system's triplet, - remote: the host or target board is considered remote if it's running on a different machine, and thus require ssh, for example, to run commands, versus simply running commands directly. Note that they are not mutually exclusive, as you can have a remote machine that has the same triplet as the build machine. From a GDB point of view: - native: when GDB uses system calls such as ptrace to interact directly with processes on the same system its running on, - remote: when GDB speaks the RSP (Remote Serial Protocol) with another program doing the ptrace stuff. Note that they are mutually exclusive. An inferior can only be either debugged with the native target, or with the remote target a specific time. That means that there are cases where the target is not remote for DejaGnu, but is remote for GDB (e.g. running GDBserver on the same machine). You can also have a remote target for DejaGnu, but native for GDB (e.g. building on x86 a GDB that runs on ARM and running the testsuite with a remote host). Therefore, care must be taken to check for the right kind of remote. Use [is_remote target] to check whether the DejaGnu target board is remote. When what you really want to know is whether GDB is using the remote protocol, because feature X is only available when GDB debugs natively, check gdb_protocol instead.