Using open-source GNU, Eclipse & Linux to develop multicore Cell apps: Part 3

The Cell SDK provides two debuggers for this purpose: ppu-gdb and spu-gdb, and both closely resemble GNU's gdb debugger. Even if the application runs without errors, it might not meet performance requirements.

In this case, you need to locate problems like pipeline stalls, branch miss percentages, and direct memory access (DMA) bus overload. No debugger can give you these statistics, but IBM's Full-System Simulator for the Cell processor, called SystemSim, provides all this information and more.

This part in this series describes SDK's debuggers and SystemSim in detail. It explains the tools' commands and gives examples of how they're used. Keep in mind, however, that the SDK also provides an integrated development environment (for Linux) that enables point-and-click debugging and simulation. If command lines make you nervous, you may want to wait until Part 5 in this series.

Debugging Cell Applications
The concept of debugging is simple: run an application until a specific line of code is reached or a specific condition occurs, then halt. Read the state of the processor and step through succeeding lines.Keep examining the processor's state until you can determine what's producing the error.

Just as gcc is the preeminent open source tool for building applications, gdb is the preeminent tool for debugging them.The Cell SDK provides two debuggers, both based on gdb. ppu-gdb debugs applications built for the PPU and spu-gdb debugs applications built for the SPU.

Both use the same commands, which are the same commands used by gdb. If you're already familiar with these commands, you might want to read Part 4 in this series, which describes the Full-System Simulator.

Debugging SPU Applications with spu-gdb
This section concentrates on spu-gdb for three reasons. First, its commands are essentially the same as those used by ppu-gdb. Second, the SPU architecture is simpler than the PPU's, so it's easier to analyze its registers and memory.Third, SPUs perform the brunt of the Cell's number crunching, so it's very important to get your SPU applications working properly.

A PPU or SPU application can be debugged only if it was compiled with -g and without optimization.The -g option inserts debug information into the executable and makes sure that each line can be executed separately. If you try to debug an optimized application, its breakpoints and watchpoints won't work correctly. A typical spu-gdb session consists of seven main stages:

1. Enter spu-gdb followed by the name of the executable.This starts the debugger.

2. At the (gdb) prompt, use break to create a breakpoint or watch to create a watchpoint.

3. Enter run.This executes the application until the breakpoint location is reached or the watchpoint condition becomes valid.

4. When the application halts, use commands such as info to examine the state of the processor.

5. Use the step, next, or continue commands to execute succeeding lines.

6. Repeat previous steps until the bug is discovered. Enter run to complete the application's execution.

7. Enter quit to end the debugger session.

To effectively use spu-gdb from the command line, you need to understand its basic instructions. This discussion divides them into three categories: commands that set breakpoints and watchpoints, commands that read processor information, and commands that control the execution of the application.