OAR

RTEMS 4.5.1-pre3 On-Line Library


DDD - Data Display Debugger

PREV UP NEXT Bookshelf RTEMS Frequently Asked Questions

7.1.3: DDD - Data Display Debugger

By far the easiest way to use DDD if you are on a Redhat or SuSE Linux system is to retrieve the RPM package for your OS version. In general, it is easier to install a static binary since doing so avoids all problems with dynamic library versions.

Some versions of DDD have had trouble with Lesstif. If you are using Lesstif, you will need version 0.88 or newer. It is also available as an RPM at the popular sites. Another Motif clone is Motive and versions 1.2 and newer known to work with DDD on popular distributions of Linux including RedHat and Slackware.

Installed as RPMs, DDD in conjunction with either Lesstif or Motive should work out-of-the-box.

User comments indicate that both Lesstif and DDD can be built from scratch without any problems. Instructions on installing DDD are at . They indicate that

So configure lesstif with --enable-default-12.

The configure script is broken (see www.lesstif.org --> known problems) for 0.88.1. I didn't fix the script as they show, so I just have links in /usr/local/lib (also shown).

Watch out: Lesstif installs its libraries in /usr/local/Lesstif. You will need to update /etc/ld.so.conf and regenerate the cache of shared library paths to point to the Motif 1.2 library.

The following notes are from an RTEMS user who uses DDD in conjunction with Lesstif. Configure DDD "--with-motif-libraries=/usr/local/lib --with-motif-includes=/usr/local/include" DDD needs gnuplot 3.7. . Build and install from scratch.

DDD can be started from a script that specifies the cross debugger. This simplifies the invocation. The following example shows what a script doing this looks like.

#!/bin/bash
ddd --debugger m68k-elf-gdb $1

Under many flavors of UNIX, you will likely have to relax permissions.

On Linux, to get gdb to use the serial ports while running as a normal user, edit /etc/security/console.perms, and create a <serial> class (call it whatever you want).

<serial>=/dev/ttyS* /dev/cua*

Now enable the change of ownership of these devices when users log in from the console:

<console> 0600 <serial> 0600 root

Users report using minicom to communicate with the target to initiate a TFTP download. They then suspend minicom, launch DDD, and begin debugging.

The procedure should be the same on other platforms, modulo the choice of terminal emulator program and the scheme used to access the serial ports. From problem reports on the cygwin mailing list, it appears that GDB has some problems communicating over serial lines on that platform.

NOTE: GDB does not like getting lots of input from the program under test over the serial line. Actually, it does not care, but it looses characters. It would appear that flow control is not re-enabled when it resumes program execution. At times, it looked like the test were failing, but everything was OK. We modified the MVME167 serial driver to send test output to another serial port. Using two serial ports is usually the easiest way to get test output while retaining a reliable debug connection regardless of the debugger/target combination.

NOTE: Enabling gdb's remote cache might prevent this (Observed with SH1 boards, but may also be valid for targets):

gdb > set remotecache

Information provided by Charles-Antoine Gauthier (charles.gauthier@iit.nrc.ca) Jiri Gaisler (jgais@ws.estec.esa.nl) and Ralf Cors@'epius (corsepiu@faw.uni-ulm.de)


PREV UP NEXT Bookshelf RTEMS Frequently Asked Questions

Copyright © 1988-2000 OAR Corporation