Tux
Communication
Mailing lists
Documentation
User Manual
Target board info.
Target chip info.
Support
Linux support
Bugzilla
Downloads
STLinux
Updates
Search
Google


The web
stlinux.com
Getting Started
Testing the GNU cross-tools with dejagnu
ST Logo
Previous   Contents   Next

Introduction

Dejagnu is a test framework used to run test suites 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. This process, while quite, is not well documented which makes running these suites on a new machine very difficult. This document provides simple directions to get the test suites running on ST40 processors.

Configuring the target

The test suites will be using SSH to communicate with the target in order to run tests and launch debug sessions. It is difficult fo the test suite to provide SSH with a password meaning that SSH must be set up to work without requiring a password. For recent (SSH2 protocol) versions of SSH this requires effort on both the host and target to permit an automatic connection using a public/private key challange.

This tutorial assumes that the user's .ssh directory does not contain a pre-existing public key. If you are an existing SSH users you may choose to adapt these instructions if you have already performed some of them.

  1. The root account on the target board must be provided with a password for ssh to work properly prior to being fully configured. If your root account has no password then use the serial console to login as root, enter 'passwd' at the shell prompt and provide a new password.
  2. At the (host) shell prompt type 'ssh-keygen -t rsa'.
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/afra/users/thompsond/.ssh/id_rsa):
  3. Press return.
    Created directory '/home/afra/users/thompsond/.ssh'.
    Enter passphrase (empty for no passphrase):
  4. Press return.
    Enter same passphrase again:
  5. Press return.
    Your identification has been saved in /home/afra/users/thompsond/.ssh/id_rsa.
    Your public key has been saved in /home/afra/users/thompsond/.ssh/id_rsa.pub.
    The key fingerprint is:
    c4:c8:58:eb:61:9c:8f:9c:25:a4:68:0c:22:7f:bc:37 thompsond@butch.bri.st.com
  6. At the shell prompt type 'ssh root@scrutock mkdir /root/.ssh', replacing scrutock with the name or IP address of your target board.
    The authenticity of host 'scrutock (164.129.14.180)' can't be established.
    RSA key fingerprint is 5f:2c:64:53:2b:fa:1e:14:38:00:6a:d4:b2:43:07:93.
    Are you sure you want to continue connecting (yes/no)?
  7. Type yes and press return.
    Warning: Permanently added 'scrutock,164.129.14.180' (RSA) to the list of known hosts.
    root@scrutock's password:
  8. Enter the root password and press return.
  9. At the shell prompt type ' scp /home/afra/users/thompsond/.ssh/id_rsa.pub root@scrutock:/root/.ssh/authorized_keys ', replacing scrutock with the name or IP address of your target board.
    root@scrutock's password:
  10. Enter the root password and press return.
    id_rsa.pub                                    100%  236     1.1MB/s   00:00
  11. SSH is now configured on both sides and can now SSH without a password. To check this type 'ssh root@scrutock' at the shell prompt, replacing scrutock with the name or IP address of your target board.
    Last login: Sat Jan  1 00:43:43 2000 from 164.129.15.35
    Linux scrutock 2.4.24_st1.7test7-st-st220eval #1 Sun Sep 19 17:17:44 BST 2004 sh4 unknown

GDB

The following describes how to test GDB as a cross-debugger (using gdbserver) against binaries built on the host with a cross-compiler.

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

Rather than using the packaged dejagnu RPM supplied with Redhat/Fedora Core we will be downloading and tarball release. Primarily we use the tarball release because we can there are bugs in the cross-testing code that must be fixed before running the test suite. Additionally using a tarball release also hides a minor in the GDB build system.

  1. Build stlinux20-cross-gdb from its source RPM. This will provide a gdb source tree, suitably configured and built, in the RPM BUILD folder.
  2. Download and unpack the dejagnu sources. At the time of writing, the most recent release (1.4.4) contains a bug in the remote command execution code. The following patch must therefore be applied to the source after is unpacked:
    --- 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 build (configure && make).
  3. Create a file ~/.dejagnurc containing the following:
    set target_list "sh4-linux"
    lappend boards_dir "~/.dejagnu.d"
    
  4. Create a file ~/.dejagnu.d/sh4-linux.exp containing the following:
    load_generic_config "gdbserver"
    
    process_multilib_options ""
    
    # Set up the C and C++ compiler paths
    set_board_info compiler  "/opt/STM/STLinux-2.0/devkit/sh4/bin/sh4-linux-gcc"
    set_board_info c++compiler  "/opt/STM/STLinux-2.0/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's no support for argument-passing (yet).
    set_board_info noargs 1
    
    # Can't do input (or output) in the current gdbserver.
    set_board_info gdb,noinferiorio 1
    
    # Can't do hardware watchpoints, in general
    set_board_info gdb,no_hardware_watchpoints 1
    
  5. Switch to .../BUILD/gdb-6.3 and softlink the dejagnu distribution directory to dejagnu, for example ln -s ~/dejagnu-1.4.4 dejagnu .
  6. Switch to .../BUILD/gdb-6.3/objdir/gdb/testsuite and run make check .

This test suite has a long run time but issues frequent console output to show it is still running. It will eventually complete displaying a summary similar to the following (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 ST40 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/afra/users/thompsond/Development/rpmbuild/BUILD/gdb-5.3/objdir/gdb/testsuite/../../gdb/gdb version  5.3 -nx

Previous   Contents   Next
Valid HTML 4.01! Last updated: 2005/01/06 13:28:21
© Copyright STMicroelectronics Limited, 2005
Printer