Download Pro Linux Embedded Systems

CHAPTER 10
■■■
Debugging Applications
Getting Started on Your Application
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 chapter 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 chapter 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 chapter 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.
215
www.it-ebooks.info