Remote debugging tools and Linux development techniques

Remote Debugging with GNU Emacs

Emacs is a great all-around tool for software development. If you haven't already installed it, use one of the prepackaged Emacs distributions available through the package manager with your Linux distribution. If you're running a system using the Debian package-management system, do the following:

$sudo apt-get install emacs

Or do this, if you have an RPM-based system:

$sudo yum install emacs

Emacs is available in source form if there are no prebuilt binaries for your platform. If possible, use the prebuilt distributions of Emacs. Emacs contains a Lisp interpreter that provides a widely used mechanism for developing extensions. One extension included with the standard Emacs installation is for C and C++ development, as mentioned earlier in the article. This extension has a front end for the GDB debugger and works well for remote debugging because it provides you with a mix of access to the GDB command line and pointand- click debugging. Access to the command line is important when you're starting a debugging session; afterward, you can use the GUI as the primary way to interact with the debugger. When you're debugging C or C++ files, Emacs loads some software that adds menu entries appropriate for the file type. To open the debugger, select Tools > Debugger (GDB). In the mini-window at the bottom, enter the command to launch the GDB for the target platform. The debugger loads and presents a command prompt for the GDB you just loaded. When you're In this mode, the method for setting up a remote connection is exactly the same as the command-line GDB. You're responsible for getting the code to the target machine before debugging.

After you establish the connection to the remote machine, you can set breakpoints by clicking in the gray area to the left of the line. To step through code, use the icons under the menu. If you've used Emacs to debug local programs, there is virtually no difference after the program has started running. Emacs stores the last state of the debugger at the beginning of the Linux project, so the next time a debugging session starts, you won't need to type as much to start a debugging session. Emacs also keeps track of breakpoints between debugging sessions.

Remote Debugging with Eclipse

Eclipse contains interesting tools for remote debugging that are part of the Eclipse platform: CDT and DSDP. Because the embedded development parts of Eclipse are leading edge, you need to download the latest Eclipse distribution and packages for embedded development and debugging. Unlike the other tools in this article, Eclipse isn't a debugger-it's an entire IDE. In order to use just the debugging features, you must import your Linux project into Eclipse and possibly restructure how the project builds. If you're starting a new Linux project and use Eclipse from the beginning, this isn't a factor. If you have an existing Linux project and just want to use the debugging features of Eclipse, you may want to consider using one of the other tools in this article. After it's unpacked, the software is ready to run in the directory where it was unpacked. You can relocate this directory to your /opt or /usr/bin directory; but Eclipse runs just fine in any directory. When you have Eclipse in the desired directory, run it. Then, do the following to install the Target Management and Device Debugging plug-ins that extend Eclipse functionality:

1. Select Help > Software Updates.

2. In the Software Updates and Add Ons dialog, click the Add Site button.

3. The software churns for a little while and then presents you with a list of software to install. Select all the items in the list.

4. The wizard walks you through the installation process, asking you to agree to license terms and confirm your selections. After installation, the software asks you to restart.

Eclipse is now updated with the correct plug-ins for remote C and C++ debugging. The first package installed is a tool that manages a remote target; you can use it to copy files to the target without resorting to going to the command line. To start a remote debugging session, select Run > Debug Configurations, and double-click the C and C++ Remote Application item to create a new empty Debug Configuration. The program that's being debugged is less important that the process of configuring Eclipse for remote debugging.

Supply a name for the configuration (it can be anything). The next thing of interest is the connection: this is where you tell Eclipse how to communicate with the remote target when starting a debug session or downloading files. Click the New button to start the wizard. You're asked the type of system, with Linux being an obvious choice. Don't be tempted, because this configures Eclipse to communicate with an agent, dstore, that hasn't been installed on most systems; instead, select Ssh Only, because most embedded systems have small versions of SSH installed. The next panel asks you for the IP address or host name of the remote machine. In this example, the IP address is 192.168.10.21, but it will likely be different for you. The connection name defaults to the host name or IP address; the Description field is optional. The last two panels in the wizard define how Eclipse opens a shell on the target and transfers files. Back at the Debug Configuration panel, fill in the name of the Linux project containing the sample program. Next, click the Search Project button, and select the binary for your Linux project. Make the remote path /tmp/remote the place to download the binary to the target machine. You must have write privileges for this directory or the download will fail.

The next step is to switch to the Debugger tab and select a debugger. The default value for this field is GDB, which is the debugger residing on the host system, not on the target. Click the Browse button next to the field, and select the debugger you built earlier in the article or the one that was built with the toolchain. If you're curious, there's a drop-down for selecting the protocol where you can select Default, mi1, mi2, or mi3. This field means the version of the machine interface protocol that Eclipse should use when communicating with the debugger. You only need to set this if the debugger in use is older and must use one of the older protocols. For the most part, Default is an acceptable value. Now, you're ready to debug. Click the Apply button, and then Debug. A small dialog appears, asking for a user name and password for the remote host, to be used for transferring the file and opening the shell. The application file is downloaded, and the debugger starts. The debugging works the same as if you were debugging locally.

Debugging Java

This article discusses how to remotely debug Java using the tools offered by Eclipse. Remotely debugging Java is much like remotely debugging a C program: you make a connection with a remote target that is running some software that lets you control program execution and inspect values from memory. Java isn't that much different from a lower-level language like C. Java source code is compiled into byte code for a Java Virtual Machine that runs on top of a host machine. The way Java has been engineered, that host machine should have no effect on how Java runs; and this is how things work, to a great degree. When you think about it, all development done in Java is like embedded development, because the code is cross-compiled.

When you run code for a debugging session, you start the virtual machine in a state where it waits for a connection from a remote machine, similar to the way gdbserver waits for a connection to start debugging. After you make the connection with the debugger, the remote virtual machine waits for commands to step through the code and return the values of variables. You can do this from the command line, but the most practical and common way of creating and debugging code is with Eclipse. This article focuses on using Eclipse to create the code and start the remote debugging session. Fortunately, with Java development and debugging, there are no additional packages to download or install-everything necessary for remote debugging is included with the standard Eclipse installation or download. The remote debugging protocol is an extension of the standard JVM. Make sure you're using a Sun or IBM JVM, because these implementations contain the code necessary to support debugging. To see what version is installed, do the following:

$ java -version
   java version "1.5.0"
   gij (GNU libgcj) version 4.3.3

If you see this output, you need to install either Sun's or IBM's java. The GNU implementation of Java is frequently installed by default, but it doesn't have the code necessary for remote debugging. Visit http://sun.java.com, and install the correct version of Java; or use your package manager to install the correct versions. After installing Java from your preferred source, update the path so that the first entry is for the location of the java executable you want to use. When you install Java on Ubuntu, it doesn't override the GNU Java path. Put the path to the Sun or IBM Java first in your path. When you use the GNU Java, you can start the Java JVM, and it will accept the parameters for starting a remote debugging session; but when you start the remote debugging process with Eclipse, it just runs the program, ignoring any breakpoints and not presenting any error or warning messages. The lack of error or warning messages can make figuring out what is wrong a frustrating process. To start a remote debugging session, you need to run the Java VM with some special parameters in order for it to wait for a debugging connection. For example, let's say you create a very simple class (hello) packaged in a jar file (test.jar) and put it on a remote machine.