In the host environment, debugging an application that runs on top of the operating system is done by running a debugger tool, which can attach to an existing process, or spawn a new one given an executable ELF file and its command-line arguments. The default debugging option provided by the GCC suite is called GDB, an acronym for the GNU Debugger. While GDB is a command-line tool, several frontends have been developed to provide a better visualization of the state of the execution, and some integrated development environments provide built-in frontends for interacting with the debugger while tracing the single lines being executed.

Once again, the situation is slightly changed when the software to debug is running on a remote platform. A version of GDB, distributed with the toolchain and specific for the target platform, can be run on the development machine to connect to a remote debug session. A debug session on a remote target requires an intermediate tool that is configured to translate GDB commands into actual actions on the core CPU, and the related hardware infrastructure, to establish the communication with the core.

Some embedded platforms provide hardware breakpoints, which are used to trigger system exceptions every time the selected instructions are executed.

Later on in this chapter, we'll see how a remote GDB session can be established with the target, in order to interrupt its execution at the current point, proceed to step through the code, place breakpoints and watch points, and inspect and modify the values in memory. A handful of GDB commands are introduced, giving a quick reference to some of the functionalities provided by the GDB command-line interface, which can be effectively used to debug embedded applications.

The debugger gives the best possible understanding of what the software is actually doing at runtime, and facilitates the hunt for programming errors while directly looking at the effects of the execution on memory and CPU registers.