Even for an experienced developer, gdb's command line interface may be awkward to use. Not only can it be difficult to understand the syntax for such simple tasks as displaying the members of a struct, but since you work in a single terminal window all output goes there and invariably clutters your view of the code. In addition to that, you often end up with a separate editor to have syntax-colored code, a separate window to get that nice disassembly mixed with your source code. Fortunately, there are several GUIs to use with gdb, and it's easy too. I have selected some of them that are in active development to show you how to set them up to work with gdb-cris. Here's a quick overview:

RedHat project. Lives in the same cvs source tree as gdb itself. First release in July 1999.

GNU project. Been around since 1995.

GNU project. First release (probably) in 2000.

GNU project.

Tested version

Insight+gdb cvs snapshot from 2001-08-06

DDD 3.3

GVD 1.2.0

GNU Emacs 20.7.2

Binary/source available

No binaries are distributed. Source is available via ftp/cvs. Insight is built with gdb. Uses tcl/tk.

Source available via ftp/cvs. Binaries available in distros (Debian and RedHat).

Both. Binaries are likely to be preferred since GVD is written in ADA and requires GNAT and GtkAda to be built.

Both. (It's very likely that Emacs is already installed on your system.)

Functions/GUI

Very nice and intuitive. Has all the basic functions. Multi-window GUI.

Almost feature-bloated. Very configurable with respect to gdb itself. Can plot data in 3d. Single or multi-window GUI.

Has all the basic functionality. GUI and menus resemble that of DDD. Single-window GUI.

Provides Emacs' excellent syntax-coloring, and a split window for GDB's command line interface.

These are all competent enough to do the job. Ultimately, it will be a matter of taste which one you'll end up using. They all have the possibility of bringing up a console window that lets you interface directly with gdb's command line interface, so you can mix those commands with the point-and-click feature of the GUI as you wish. No functionality lost, only gained.

The procedures described below are only one way of doing things. The URLs above all contain links to comprehensive manuals for each of the GUIs.

Insight lives in the same cvs source tree as gdb, and since the CRIS port of gdb is in the official sources you can download insight+gdb according to the instructions on sources.redhat.com/insight. Then simply configure and build gdb-cris according to the installation instructions. No special arguments are required to configure; Insight will automatically be built with gdb-cris if it's included in the same source tree.

You may be pleased to know that you can still run gdb-cris without Insight. Simply invoke gdb-cris with the –nw option (for “no window”) to start gdb-cris with only the built-in command line interface. No need to have two versions of gdb-cris installed.

Assuming you have a gdbserver running on a developer board with IP address 10.13.8.122, communicating over TCP/IP on port 2345, what you need to do to connect is the following:

File→Open: choose the executable file that you want to debug.

File→Target Settings: you need to specify how to connect to the target. Target should be set to Remote/TCP, Hostname to 10.13.8.122 and Port should be 2345. Also, you probably want to check the “Attach to Target”, “Set breakpoint at 'main'”, and “Continue from last stop” boxes.

Run→Run should now land you comfortably on the first line in the main() function of your program.

If you choose not to check the suggested boxes under point 2, attaching to the target (with Run→Connect to target) will leave you in whatever startup function your C library has, which may lack debug information. In that case Insight won't be able to make any sense of where it is, and you will have to set a breakpoint at main() manually and issue a continue. Setting the breakpoint is easily done by right-clicking on the main() function in the source code window and choosing Set Breakpoint at main.

When you start DDD, you need to specify the actual debugger to use. The default debugger is the gdb installed on your system (probably a native debugger for your processor and operating system). To do that, you invoke DDD like this:

ddd --debugger gdb-cris

I have not been able to find a menu in DDD 3.3 which lets you specify the debugger to use; please let us dev-etrax@axis.com know if you should happen to find it. However, you can specify the debugger to use in your ~/.ddd/init file by adding the line Ddd*debuggerCommand: gdb-cris.

Assuming you have a gdbserver running on a developer board with IP address 10.13.8.122, communicating over TCP/IP on port 2345, what you need to do to connect is the following:

File→Open Program: choose the executable file that you want to debug.

Connecting to the target in DDD can be done via the command line interface, which should be at the bottom of the DDD window. In our case, target remote 10.13.8.122:2345 will do the trick. Another way is to make a user-defined button for this command, which is an excellent feature in DDD. In Commands→Define Command simply put target remote 10.13.8.122:2345 in the Command edit box, and check one (or more) of the checkboxes. Now a button appears that carries out this command when you press it.

Now you may choose to set a breakpoint on the main() function and issue a continue either from the command line interface or via the GUI. Setting the breakpoint is easily done by right-clicking on the main function and choosing Break at main.

As with DDD, when you start GVD, you need to specify the actual debugger to use. The default debugger is the gdb installed on your system (probably a native debugger for your processor and operating system). To do that, you invoke GVD like this:

gvd --debugger gdb-cris

You can also choose the debugger to use in the File→New Debugger menu. Specify gdb-cris in the Debugger Name field, and keep the Replace Current Debugger checkbox checked.

Assuming you have a gdbserver running on a developer board with IP address 10.13.8.122, communicating over TCP/IP on port 2345, what you need to do to connect is the following:

File→Open Program: choose the executable file that you want to debug.

You may have noticed that the File→ New Debugger menu contains some fields for Program File, Program Host and Protocol. They don't seem to work very well, so I suggest you switch to the command line interface at the bottom of the GVD window for this procedure. Like in the DDD example, target remote 10.13.8.122:2345 will do the trick.

Again, you may choose to set a breakpoint on the main() function and issue a continue either from the command line interface or via the GUI. Also in GVD, the quickest way is right-clicking the main() function and choosing Set Breakpoint on main.

(where M is whatever key you use for the Meta key; Esc, Ctrl or Alt is common) which displays the prompt “Run gdb (like this):” to which you add gdb-cris.

Run gdb (like this): gdb-cris

You fall into gdb-cris just as you would if you had run it outside of Emacs.

Assuming you have a gdbserver running on a developer board with IP address 10.13.8.122, communicating over TCP/IP on port 2345, what you need to do to connect is the following:

Type file <file name of program to debug>

Connect to the target with target remote 10.13.8.122:2345.

You land in the startup routine of the C library your program uses. Now break main and then continue

Now Emacs will split into two windows, one with gdb's command line interface, and the other showing the source code of your file. There is now a new menu in Emacs called Gud which gives you access to the basic gdb commands.