|
Start Your Application Now
Debugging consumes the lion's share of time in a project. Peeling away the wrapper around programming methodology fads usually exposes methods and practices for minimizing the time spent debugging, usually via planning and adding help during the debugging phase. Part of this article is dedicated to practices that reduce debugging, but mostly it focuses on tools to use when you're debugging. The information is mixed, because it's sometimes difficult to separate one topic from the other. This article covers debugging both C/C++ and Java programs in detail, using remote debuggers. Engineering projects using these languages do a fair amount of debugging remotely, and knowing how to get this debugging setup running is an important part of the project. As you've seen so far with Linux, there are at least three different ways to do everything, and debugging provides more of the same. The techniques for instrumentation transcend language; they just have implementation differences. Embedded engineers fall back on instrumentation because you can't find defects that are timing related by stepping through the code. Even though remote debugging technologies have improved vastly over the years, the favorite debugging tool for embedded engineers remains printf().
Types of Debugging
There are a few different ways to look at application debugging: interactive, post mortem, and instrumentation. This article focuses on the first and last debugging types with the most detail, because they're the most commonly used and productive techniques. Due to the space limitations on embedded systems, getting a core dump for post-mortem debugging isn't that common, but the concept does merit mention for systems that are less memory constrained. Following are descriptions of the three approaches:
- Interactive: This is what comes to mind first for debugging. The process consists of stepping through the code a line at a time (so called single-stepping) and examining the state of memory as well as observing program flow. When singlestepping gets tedious, you use break points to stop execution on certain lines. Interactive debugging is great at finding logic problems, but the act of debugging makes it impossible to find timing bugs: single-stepping through the code doesn't change the sequence of the code but does change what else in the system gets a chance to run while the current program is being debugged. As such, this is a small example of the Heisenberg uncertainty principle, where the act of measurement affects what is being measured.
- Post mortem: This means "after death," and it involves looking at the state of the application or system after it has stopped. GDB includes the ability to examine core dump files for your target platform. Post-mortem debugging gives you the ability to see the state of the system right before the program stopped working, because it's forensic in nature; you work backward from the point of death to determine how the system died. This type of debugging is made easier when the code has some instrumentation, because you get a clearer picture of how the system arrived at its current state.
- Instrumentation: This method means debugging by adding statements to the code that print out information; you examine that information after the program runs, or maybe while the program is running, depending on how the code was instrumented. Instrumentation works best for bugs that are timing related, but even low-overhead instrumentation causes timing problems. What are timing problems? Essentially, they're a general way of describing race conditions, where the order of execution of two or more threads of code can result in an incorrect result or where two threads of execution need to use a resource in a coordinated fashion. Timing problems can also be introduced when code relies on the passage of time in order to be accurate: for example, a timer that must work every 10 milliseconds or a process that must complete work within a certain time interval.
The goal of debugging is, of course, to root out problems. However, many times engineers use debugging as a learning aid. No matter how well the documentation describes how a function call works, being able to see the results first hand and perhaps change the parameters interactively is a great technique for those who learn by experimentation. All of these debugging methods are well-supported in Linux.
Remote Debugging Overview
Debugging when the debugger and the program being debugged run on separate hosts is called remote debugging. Whereas regular debugging involves two major components (the debugger and the program being debugged), remote debugging adds one more item to the list: the debug monitor. The debug monitor is a stand-in for the debugger that's running on a different machine; during debugging, the debugger and the monitor exchange messages over a communications link, and the monitor handles the mechanics of settings the breakpoints and fetching the contents of memory when you ask to see a variable's value. When you use the GNU debugger (which is really the only C/C++ debugger for Linux), the debug monitor is gdbserver. For a Java program, the debug monitor is built into the virtual machine: when you run the program with the java executable, you pass in a few extra parameters. The way Java is structured, debugging on the machine where the program is running and from a remote machine use nearly the same communication mechanism.
Debugging C and C++
In order to debug C and C++ code, you must compile the code with debugging information. On a Linux system, that debugging information is in DWARF 2 format, the successor to the original Debugging With Attributed Record Formats (DWARF)2. DWARF 2 describes a format for storing information about line numbers and symbols as additional data in the file. With this information, a debugger can understand how the data is stored in memory and has an idea of what instructions belong with one line. When the code is compiled correctly, if it's to be debugged remotely, two programs are necessary: the debugger (GDB) and the debug monitor (gdbserver) The GDB binary runs on your development host computer, and gdbserver runs on the target. The rationale for having two programs is simple: gdbserver is much smaller and requires very few resources in order to work, whereas GDB needs quite a bit of memory, which the target machine may lack. If you're using a toolchain built with crosstool-ng, you can find the gdbserver component at /debug-root/usr/bin/gdbserver. This program is linked without shared library dependencies, so all you need to do is copy it to the /bin directory of the target system.