Remote debugging

Debugging a program running on one system while controlling the program from another
system is known as remote debugging. The debugger supports remote debugging by
allowing you to run the debugger user interface on one system, while running the debug
engine on another system. The system running the debugger user interface is known as
the local system. The system where the debug engine runs is known as the remote
system.

When debugging a program remotely, you can start the debugger in one of two ways:

• Start a debug engine daemon, then start the debugger user interface.
• Start a debugger user interface daemon, then start a debug engine.

In both cases, a daemon will listen for a connection. Once a connection is made you can
begin to debug your program.

Why use remote debugging

You might want to use remote debugging for the following reasons:

• The program you are debugging is running on another user's system, and is
behaving differently on that system than on your own.

You can use the remote debug feature to debug this program on the other system,
from your system. The user on the system running that program interacts with the
program as usual (except where breakpoints or step commands introduce delays)
and you are able to control the program and observe the program's internal
behavior from your system.

• You want to debug a program that uses graphics or has a graphical user
interface.

It is easier to debug an application that uses graphics or has a graphical user

interface when you keep the debugger user interface separate from that of the
application. Your interaction (or another user's interaction) with the application
occurs on the remote system, while your interaction with the debugger occurs on
the local system.

• The program you are debugging was compiled for a platform that the debugger
user interface does not run on.

You can use the remote debug feature to take advantage of the debugger user
interface while debugging the remote application.

Remote debugging imposes the following limitations:

 • Browse only displays the file system on the local system. The file system on the
remote system cannot be displayed.

If available, a remote debugger can be used to download, execute, and debug embedded
software over a serial port or network connection between the host and target (also called
cross-platform debugging). The program running on the host of a remote debugger has a
user interface that looks just like any other debugger that you might have used. The main
debugger screen is usually either a command-line interface or graphical user interface
(GUI). GUI debuggers typically contain several smaller windows to simultaneously show
the active part of the source code, current register contents, and other relevant
information about the executing program.

Note that in the case of embedded systems, the debugger and the software being
debugged are executing on two different computer systems. Remote debugger software
runs on the host computer and provides the user interface just described. But there is also
a backend component that runs on the target processor and communicates with the host
debugger frontend over a communications link. The debugger backend provides low-
level control of the target processor. Figure 5-2 shows how these two components work
together.

Figure 5-2. Components of a remote debug session

The debug monitor resides in ROMhaving been placed there either by you or at the
factoryand is automatically started whenever the target processor is reset. It monitors the
communications link to the host computer and responds to requests from the remote
debugger host software. Of course, these requests and the monitor's responses must
conform to some predefined communications protocol and are typically of a very low-
level nature. Examples of requests the host software can make are "read register x,"
"modify register y," "read n bytes of memory starting at address z," and "modify the data
at address a." The remote debugger combines sequences of these low-level commands to
accomplish complex debugging tasks such as downloading a program, single-stepping,
and setting breakpoints.

One such debugger is the GNU debugger (gdb). Like the other GNU tools, it was
originally designed for use as a native debugger and was later given the ability to perform
remote debugging. The gdb debug monitor that runs on the target hardware is called a
gdb stub. The GNU software tools include gdb. The version installed is CLI-based, so
there are a few commands to learn in order to run the debugger properly. There are
several GUIs available for gdb, such as Insight and DataDisplay Debugger.

RedBoot contains a gdb-compatible debug monitor. Therefore, once a host attempts to

communicate with the target using the gdb protocol, RedBoot turns control of the target
over to the gdb stub for the debug session.

As described earlier, the host and target use a predefined protocol. For gdb, this protocol
is the ASCII-based Remote Serial Protocol. Another good resource for information about
gdb is Debugging with GDB: The GNU Source-Level Debugger, by Richard Stallman,
Roland Pesch, and Stan Shebs (Free Software Foundation).

Remote debuggers are one of the most commonly used downloading and testing tools
during development of embedded software. This is mainly because of their low cost.
Embedded software developers already have the requisite host computer. In addition, the
price of a remote debugger does not add significantly to the cost of a suite of cross-
development tools (compiler, linker, locator, etc.).

However, there are some disadvantages to using a debug monitor, including the inability
to debug startup code. Another disadvantage is that code must execute from RAM.
Furthermore, when using a debug monitor, a communication channel must exist to
interface the target to the host computer.