5.2 Initialization module

The initialization module (or “init file”) has two purposes: to provide tool and target dependent procedures, and to start up an interactive tool to the point where it is ready to operate. The latter includes establishing communications with the target. All the tests for interactive programs assume that the tool is already running and communicating. Initialization modules for non-interactive programs may only need to supply the support functions.

Each test suite directory must contain (in its ‘config’ subdirectory) a separate initialization module for each target. The appropriate init file is can be named several ways. The prefered name is the os part of the canonical configuration name with .exp as the suffix. An example would be that for an m68k-coff system, the target_os part would be coff. The next way is for system where there are short filenames, or a shortcut is desired to refer to the OS name for that target. This is uses the value of $target_abbrev rather than the target_os.

The final file looked for is simply ‘default.exp’. If there is only one operating system to support, then this file can be used. It’s main purpose is to offer some support for new operating systems, or for unsupported cross targets. The last file looked for is ‘unknown.exp’. This is usually limited to error handling for unsupported targets. It’s whole contents is typically.

perror "Sorry, there is no support for this target"
exit 1

At the beginning of the init file, you must first determine the proper executable name of the tool to execute, since the actual name of the tool to be tested my vary from system to system. Here’s an example for the GNU C compiler.

global AR
# look for the archiver ar
if ![info exists AR] {
    set AR [findfile $base_dir/../../binutils/ar $base_dir/../../binutils/ar [tr
ansform ar]]
    verbose "AR defaulting to $AR" 2
}
}

global CFLAGS
if ![info exists CFLAGS] then {
    set CFLAGS ""
}

It is always a good idea to first check the variable, and only set it if it has not yet been defined. Often the proper value of AR is set on the command line that invokes ‘runtest’.

The findfile procedure takes as it’s first argument a file name to look for. The second argument is returned if the file is found, and the third argument is returned if the file is not found. base_dir is set internally by DejaGnu to the top level directory of the object tree.

The transform procedure takes as its argument the native name of a tool (such as ‘gcc’ for the compiler), and returns the name as configured for that tool in the current installation. (For example, a cross-compiling version of GNU CC that generates MIPS code may be installed with a name like mips-idt-ecoff-gcc.)

In a test running native, writing the Tcl code for initialization is usually quite simple. For cross configurations, however, more elaborate instructions are usually needed to describe how to talk to a remote target.

Each initialization module defines up to four procedures with standard names and purposes. The names of these procedures begin with ‘$tool’, the string that identifies tests for a particular tool: $tool_start, $tool_load, $tool_exit, and $tool_version. For example, the start procedure for GDB is called gdb_start. (Since start procedures are used differently for batch and interactive tools, however, runtest itself never calls the start procedure. Init files for interactive tools are expected to end by running the start procedure.)

The initialization module is also a good place to call load_lib to get any collections of utility procedures meant for a family of test cases, and to set up default values for any additional Tcl variables needed for a specific set of tests.

See section Target dependent procedures, for full descriptions of these procedures.