< Previous PageNext Page > Hide TOC

Debugging Essentials

When you test your program by running it from Xcode, you may observe problems in its behavior. To pinpoint the cause of these problems, you may need to examine particular source code lines. Xcode lets you analyze your code line by line to view your program’s state at a particular stage of execution. This process is called debugging. The process being debugged is known as the inferior.

To debug a program, you run it under the control of a debugger, which lets you pause programs and examine their state. Xcode provides an interface to several debuggers.

When you debug a product, Xcode opens a debugging session with a debugger and your product’s binary. Before you can debug a program, however, it should contain as much debugging information as possible, so that Xcode can provide you with accurate and useful information during your debugging. See “Building for Debugging” in Xcode Project Management Guide for information about how to build a program to debug.

You may also debug a running process (not launched by Xcode). This operation is known as attaching to a process. You can attach to a program running under Xcode or to any process for which you have a process ID. To attach to a running program use Run > Attach to Process.

This menu lists currently running programs launched from Xcode, identified by the program name and the name of the corresponding Xcode project. (This menu also lists other programs running on the computer.) You can use the menu’s Process ID option to attach to any process using its process ID, which you obtain using UNIX utilities such as top.

Note: When you launch a program from Xcode, you can also have Xcode automatically attempt to attach the debugger to the process when the program crashes. See "Executable-Environment Debugging Information" in Xcode Project Management Guide for details.

You can perform debugging operations in several ways:

The rest of this chapter describes requirements and essential concepts of the Xcode debugging environment.

In this section:

Building a Product with Debugging Symbols
DWARF Debug Information Format


Building a Product with Debugging Symbols

Before you can take advantage of the source-level debugger, the compiler must collect information for the debugger. To generate debugging symbols for a product, enable the Generate Debug Symbols (GCC_GENERATE_DEBUGGING_SYMBOLS) build setting and build the product. This setting is enabled by default in the Debug build configuration. If you use this build configuration as the active build configuration when you build your target, the compiler generates the necessary debugging information.

To view the build settings that are set in the Debug build configuration:

  1. In the project window, select the target or targets you want to build and bring up the target editor.

  2. Click Build to bring up the Build pane.

  3. Choose Debug (or Development) from the Configuration pop-up menu at the top of the pane. You should see the Generate Debug Symbols setting in the table of build settings. Make sure that this setting is turned on; if it is, a checkmark appears in the Value column for this setting. Otherwise, turn on the setting by clicking the checkbox in the Value column.

Important: When building your product using a build system other than Xcode, you must ensure that lazy-symbol loading is turned off. See “Debugging Preferences” for more information.

For more information about building and running programs, see Xcode Project Management Guide.

DWARF Debug Information Format

Xcode uses the DWARF debug information format to manage your programs debugging data. The Stabs format, supported in earlier releases of Xcode, is no longer supported.

Xcode can generate a separate file with your application’s debug information. This feature considerably reduces the size of the binaries you create for the purpose of debugging applications.



< Previous PageNext Page > Hide TOC


© 2009 Apple Inc. All Rights Reserved. (Last updated: 2009-01-06)


Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.