Mac OS X Leopard - ARCAism

In the upper left, GDB shows the stack. Every time a method or function is called, it is
pushed onto the stack. Each item on the stack is called a stack frame. The top stack frame is the
current method. The next frame in the stack is the method that called it, and so on down the line.
If the stack frame contains any variables, they appear to the right. This includes automatic variables,
global variables, instance variables, and so on. Each variable’s current value is listed beside
its name.
Below the stack and variable views is an editor window with the current line of code highlighted.
If the code is yours, you will just see a standard editor view. If the code is not yours, GDB
will decompile it and show you the assembly.
You can continue executing the code, or you can step over it a line at a time, observing its
effects. If the code is yours, you can edit it, but the edits will not take effect until the next build,
and if you add or remove lines, the editor’s display will no longer match the current line of execution,
making its display inaccurate.
Beneath the editor is the GDB console. The console can be revealed by dragging the separator
from the bottom of the screen, or by clicking its icon in the toolbar. The console will display
any information being logged from the application or your breakpoints. Any errors or other
feedback will also show up here.
More than just a message board, the GDB console is fully interactive. You can execute any
GDB command. My personal favorite is print object, or po for short. The po command will take
any expression and print the return value. In resolving an expression in Objective-C, GDB will
send messages to objects. That means you can interact with your objects, change their values, or
get information about them. While there are certain limitations to this, it’s not unlike the interactive
runtime environments enjoyed by users of noncompiled languages like LISP, JavaScript,
Ruby, and Python.
Inline Debugging
Xcode’s traditional debugging interface is very powerful, but it suffers from the same problem as
the old build results system. That is, it interrupts the programming flow by taking you out of the
editor and thrusting you into a different environment. Sometimes you don’t need quite as much
power as the full interface provides. For times like these, Xcode provides a new inline debugging
interface, as shown in Figure 25-19.
Figure 25-19. Xcode’s new inline debugging environment
CHAPTER 25 MAC OS X DEVELOPMENT: THE TOOLS 471