Like all tools, newlib can be tested with a DejaGnu test suite. DejaGnu must be installed on the test machine.

If you already have testing set up for other tools in the GNU tool chain on your target, then you can skip the remainder of this section, and just test newlib from the build directory with the following.

	  cd bld-or32
	  make check-target-newlib
	

If this is the first time you have tried testing, then you'll need to set up your system appropriately. Once this is done, you will be able to test all the GNU tool chain components.

The tests require a target on which to run the tests. This can be a physical machine, or it can be a simulator for the target architecture.

The details of the target are provided in an expect board configuration file. This is referenced from the DejaGnu global configuration file. The environment variable DEJAGNU should point to the global configuration file.

For the OpenRISC 1000 , the global configuration file is in site.exp and a subdirectory, boards contains or32-sim.exp, which is the board configuration file for the OpenRISC simulator target.

The site.exp file has two functions. First, it must add the boards directory to the list of board directories to search. Secondly, it must ensure that the target triplet name is mapped to the name of the board configuration file.

This site.exp file can be reused for checking other targets in the GNU tool chain, which may have a different test suite hierarchy. We cannot therefore just reference the boards directory relative to the test directory. All we know is that it will be in one of the directories above, and there is no other boards directory in the hierarchy, so we add all the possible directories. Not elegant, but effective.

#Make sure we look in the right place for the board description files
if ![info exists boards_dir] {
        set boards_dir {}
}

# Crude way of finding the boards directory
lappend boards_dir "${tool_root_dir}/../boards"
lappend boards_dir "${tool_root_dir}/../../boards"
lappend boards_dir "${tool_root_dir}/../../../boards"
lappend boards_dir "${tool_root_dir}/../../../../boards"

global target_list
  case "$target_triplet" in {
    { "or32-*-elf" } {
        set target_list { "or32-sim" }
    }
  }
	

Within the boards directory, the board configuration file, or32-sim.cfg gives all the details required for the configuration.

The tool chains supported by this board are specified first. In the case of the OpenRISC 1000 , only one is supported.

set_board_info target_install {or32-elf}
	

We then need to load some generic routines, and the generic board configuration.

load_generic_config "sim"
load_base_board_description "basic-sim"
	

The default settings assume that a program is executed on the target by a command named run, built in a target specific subdirectory of the top level sim directory. In the case of the OpenRISC 1000  this directory would be sim/or32.

At a minimum, run takes as argument an executable to run, and returns the exit code from that executable as its result.

The sim directory is usually distributed as part of GDB. Simulators may be derived from CGEN specifications of the architecture, or by integrating third party simulators. The latter is the case for the OpenRISC 1000 .

The default settings for a target are obtained using the setup_sim procedure.

setup_sim or32
	

The remainder of the file is used to configure variations on the default settings. This is done using the set_board_info procedure.

The OpenRISC 1000  simulator needs an additional argument, which is a configuration file for the simulator. We know that file will be in the libgloss target directory and named sim.cfg. We can use the lookfor_file procedure to search up from the current source directory to locate the file.

set cfg_file [lookfor_file ${srcdir} libgloss/or32/sim.cfg]
set_board_info sim,options "-a \"-f ${cfg_file}\""
	

A number of helpful procedures make it easy to locate parts of the tool chain and their default arguments. For the OpenRISC 1000  we make one change, which is to specify -mor32-newlib for the linker flags, so that the newlib BSP will be used.

process_multilib_options ""
set_board_info compiler "[find_gcc]"
set_board_info cflags "[libgloss_include_flags] [newlib_include_flags]"
set_board_info ldflags "[libgloss_link_flags] -mor32-newlib [newlib_link_flags]"
set_board_info ldscript ""
	

Not all targets have the same functionality, and the remaining options specify those limitations. This is a generic board specification, so some of these apply to testing components other than newlib. The limitations specified will mean that some tests, which are inappropriate do not run.

For the OpenRISC 1000  we specify that the simulator is fast, that programs it runs cannot be passed arguments, that it does not support signals (for testing GDB) and that the maximum stack size is 64KB (for testing GCC).

set_board_info slow_simulator 0
set_board_info noargs  1
set_board_info gdb,nosignals  1
set_board_info gcc,stack_size 65536
	

We can now set DEJAGNU to point to the global configuration directory, change to the build directory and run the make command to check newlib.

	  export DEJAGNU=`pwd`/site.exp
	  cd bld-or32
	  make check-target-newlib
	

The good thing is that this set up is generic across all the GNU tool chain, so all the other tools can be checked in the same way.