Home › Development › Building

dejagnu is a test framework used to run test suites which are included with a large number of the GNU tools. Although the test suites are designed to work quickly and easily for self-hosted toolsets, it is also possible to run them on cross-tools. The process is not well documented, so running these suites on a new machine may be difficult. This section provides simple directions on how to get the test suites to run on SoC processors.

Configuring the target

The test suites use SSH to communicate with the target in order to run tests and launch debug sessions. As it is difficult for the test suite to submit passwords, SSH must be configured so as not to require a password. For recent versions of SSH (the SSH2 protocol), work must be done on both the host and the target to permit an automatic connection using a public/private key challenge.

This tutorial assumes that the user does not have a .ssh directory which already contains a public key. If SSH has previously been configured, it may be necessary to amend some of the steps.

In these instructions, replace /home/ with the name of the home directory to be used on the host machine, and replace with the name or IP address of the target.

  1. The root account on the target board must have a password in order that SSH works properly before it has been fully configured. If the root account does not have a password already, then login as root via the serial console, enter passwd at the shell prompt, and provide a new password. (This password may be removed again after SSH is fully configured by using the password root -d command.)

  2. Create a public key by typing the following on the host at the shell prompt (note that there are no spaces in ssh-keygen):

    3. host# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/<user>/.ssh/id_rsa):

  3. Press Return (to use the default directory).

    4. Created directory '/home/<user>/.ssh'.
Enter passphrase (empty for no passphrase):

  4. Press Return (to leave the passphrase blank).

    5. Enter same passphrase again:

  5. Press Return again. 

    6. Your identification has been saved in /home/<user>/.ssh/id_rsa.
Your public key has been saved in /home/<user>/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx <user>@<machine>

  6. Create a directory .ssh on the target by typing: 

    7. ssh root@<target> mkdir /root/.ssh

    and press Return:

    The authenticity of host '<target>' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)?

  7. Type yes and press Return:

    8. Warning: Permanently added '<target>' (RSA) to the list of known hosts.
root@<target>'s password:

  8. Enter the root password of the target machine and press Return.

  9. To transfer the public key to the target type:

    10. host% scp /home/<user>/.ssh/id_rsa.pub \
            root@<target>:/root/.ssh/authorized_keys
root@<target>'s password:

  10. Enter the root password of the target and press Return:

    11. id_rsa.pub                                    100%  236     1.1MB/s   00:00

SSH is now configured on both sides and will work without a password. To check this, type the following at the shell prompt on the host:

host% ssh root@<target>
Last login: Sat Jan  1 00:43:43 2000 from 164.129.15.35
Linux <target> 2.6.11 #4 Sun Sep 18 17:17:44 BST 2005 sh4 unknown unknown GNU/Linux
Welcome to STMicroelectronics Base Distribution

Using dejagnu

This section describes how to use dejagnu to test binaries built on the host with a cross-compiler.

Note: Testing GDB as a self-hosted debugger is simple (in theory at least) as dejagnu defaults to running self-hosted tests.

Rather than using the packaged dejagnu RPM supplied with Red Hat/Fedora Core, it is better to download a tarball release. The main reason for this is that there are bugs in the cross-testing code which must be fixed before running the test suite. There is also a minor problem in the GDB build system also fixed by using the tarball release.

The procedure for installing dejagnu and GDB is given below.

  1. Build stlinux23-cross-gdb from its source RPM. This provides a GDB source tree, suitably configured and built, in the RPM BUILD folder.

  2. Download and unpack the dejagnu sources. The most recent release tested (1.4.4) contains a bug in the remote command execution code. To fix this the following patch must be applied to the source after it has been unpacked:

    3. --- dejagnu-1.4.4-orig/lib/remote.exp   2003-10-11 07:42:46.000000000 +0100
+++ dejagnu-1.4.4/lib/remote.exp        2005-01-05 14:46:44.635002000 +0000
@@ -865,7 +865,8 @@
if ![board_info $dest exists username] {
set rsh_useropts ""
} else {
-        set rsh_useropts "-l $username"
+        set username [board_info $dest username]
+        set rsh_useropts "-l$username"
}
 
if [board_info $dest exists hostname] {

    Following this, dejagnu should be configured and built using configure and make.

  3. Create a file ~/.dejagnurc containing the following:

    4. set target_list "sh4-linux"
lappend boards_dir "~/.dejagnu.d"

  4. Create a file ~/.dejagnu.d/sh4-linux.exp containing the following:

    5. load_generic_config "gdbserver"
 
process_multilib_options ""
 
# Set up the C and C++ compiler paths
set_board_info compiler  "/opt/STM/STLinux-2.3/devkit/sh4/bin/sh4-linux-gcc"
set_board_info c++compiler  "/opt/STM/STLinux-2.3/devkit/sh4/bin/sh4-linux-g++"
 
# Set up the network settings
set_board_info rsh_prog /usr/bin/ssh
set_board_info rcp_prog /usr/bin/scp
set_board_info protocol standard
set_board_info hostname scrutock
set_board_info sockethost "scrutock:"
#set_board_info gdb,socketport "4004"
set_board_info username root
 
# We will be using the standard GDB remote protocol but use a custom
# executable if required.
set_board_info gdb_protocol "remote"
#set_board_info gdb_server_prog "../gdbserver/gdbserver"
 
# Use techniques appropriate to a stub
set_board_info use_gdb_stub 1
 
# This gdbserver can only run a process once per session.
set_board_info gdb,do_reload_on_run 1
 
# There is no support for argument-passing (yet).
set_board_info noargs 1
 
# Cannot do input (or output) in the current gdbserver.
set_board_info gdb,noinferiorio 1
 
# Cannot do hardware watchpoints, in general
set_board_info gdb,no_hardware_watchpoints 1

  5. Switch to .../BUILD/gdb-6.5 and softlink the dejagnu distribution directory to dejagnu, for example:

    6. host% ln -s ~/dejagnu-1.4.4 dejagnu

  6. Switch to .../BUILD/gdb-6.5/objdir/gdb/testsuite and run:

    7. host% make check

    This test suite may take a long time to run, but it produces console output frequently to show that it is still running. It eventually completes, and displays a summary similar to that below (which is taken from a unreleased version of GDB 5.3). The number of unexpected failures is largely (but not entirely) due to the fact that the SoC version of GDB does not support backtrace from signal handlers.

    === gdb Summary ===
 
# of expected passes            4869
# of unexpected failures        1730
# of unexpected successes       2
# of expected failures          65
# of unresolved testcases       87
# of untested testcases         3
# of unsupported tests          7
/home/<users>/Development/rpmbuild/BUILD/gdb-5.3/objdir/gdb/testsuite/../../gdb/gdb version  5.3 -nx