Previous | Next

Debugging a program

Xcode also comes with a debugger that lets you watch your program execute, live. For this to work, you have to make sure the Active Build Configuration is set up for debugging. You can do this either using the popup menu in the project window's toolbar, or via the "Project" menu's "Set Active Build Configuration" menu item.

The "Debug" build configuration uses ZeroLink, which makes debugging large projects faster, but also makes your code dependent on your computer. So, if you want to give your application to someone else, always remember to switch to the Release build configuration, or your program will not run on another Mac.

Once you have your build configuration set for debugging, open your main.c source file and click in the grey "gutter" at the left of the first command of your main() function. In the case of Xcode's "Hello World" example, that would be the printf( "Hello, World!\n" ); line. A blue "pointing thing" will show up. This is what's called a "breakpoint", or "debug checkpoint" and will cause the debugger to stop before executing that line. To remove a breakpoint, simply drag it out the left of the window. Now choose "Build and Debug" from the "Build" menu (or if you already built in debug configuration above, you can also choose "Debug Executable" from the "Debug" menu).

The debugger window will show up, start running your application, and then stop at the breakpoint. It will mark the current line with a blue highlight and a red arrow to its left. You can now look at the values of all your local variables using the "Variables View" list at the upper right, and even follow pointers and look into arrays by clicking the little triangles next to them. The list to the left shows your call stack. Right now, we only have one function, but if you were in a function called by another function, you could use that list to look at the variables in the calling function, etc.

If you were to click the "Continue" icon in the toolbar now (or chose the "Continue" menu item from the "Debug" menu), your program would just keep running, finish and quit. But if you want to follow your program along as it runs, you can use the "Step Over" and "Step Into" buttons to step through your program, line-wise, where "Step Into" will go into any functions you call and let you step through them line-wise, too, while "Step Over" will see a function as just one command.

You can also click the "Console" icon to see the familiar console. While the program is paused in the debugger, the console behaves specially, in that it lets you talk directly to the GNU Debugger (aka gdb) that Xcode uses under the hood (just like it uses gcc). But you'll probably not need to talk to gdb directly anytime soon, so you can safely ignore that.

I encourage you to have some fun now: Take the project for one of our more complex sample programs, set a breakpoint in its main() function at the first line, and step through it. There's no better way to get a feeling for how your computer works than actually watching it do something. Also, don't forget to follow some pointers using the little triangles in the variables view. There's also a number of "Tools" in a submenu in the "Debug" menu, including the "Memory Browser", where you can type in an address and view it as a hex dump. Addresses are usually not shown in decimal, but in hexadecimal, and prefixed with 0x. You can use Apple's Calculator application in Programmer mode to convert between decimal and hexadecimal.

Navigating around your Code Efficiently

Whenever you have source code open in Xcode, you can double-click any word with the command key held down to be brought to its definition. I.e. if you're calling a function and want to know what it does, or what its parameters were again, command-double-click and you're there. This also works for system commands, and sometimes their headers even contain useful comments. If you do the same on a definition, you will be brought to its declaration instead, which is handy when you need to keep declaration and definition in sync after changing one of them.

There's another neat trick for system commands: Hold down the option key while double-clicking instead of the command key, and Xcode will open the Documentation Browser (available from the "Help" menu) and look up that constant, function, struct or whatever.

If there are several results for this identifier, it'll put up a popup menu listing all of them after the second click. Select the one you want from there.

After doing this for a while, you will probably find yourself looking at Apple's headers a lot, and you'll likely even remember what commands were in what header. In that case, you can use the "Open Quickly" menu item to quickly jump to a particular header, either by selecting the header file's name in a #Include statement, or by selecting nothing and then typing in the header name.

Another nice feature is the "String Match" search field at the right end of the project window toolbar, which lets you search for a particular file in the selected group. This is handy especially for huge, collaborative projects where you may not remember the exact file name. Just enter the part you remember and then click it. A handy shortcut is typing the "Home" key above the arrow keys on your keyboard while the string match field has keyboard focus: That will select the blue "Project" icon and make your search go over all files in the project. (For MacBook users, hold down the fn-key and press the left arrow key).

What else Xcode can do for You

Xcode also has contextual menus with nice features. For example, you can show the types of variables in the debugger's Variables View, reveal the position of a file in the Detail View of your project in the Groups & Files view, or show a file in the Finder that you have in your project.

And finally, Xcode has a "Preferences..." menu item where you can activate distributed builds to use other computers you may have around the house to compile part of your projects and thus make large projects faster (that requires those computers to have the same system version and Xcode version installed, though, and you can't mix PowerPC and Intel Macs), choose some more tasteful colours for syntax coloring (if you ask me, comments should stand out, so make them red!), and activate lots of other nice features (but be careful -- last I checked the auto-indentation stuff was horribly broken, and CodeSense is only something for newer Macs, so on a G4 you might want to turn it off lest it make typing unbearably slow, and Predictive compilation also slows down even a Mac Pro way more than it helps).

Previous | Next

Reader Comments: (RSS Feed)

No comments yet

Comment on this article: Name: E-Mail: (not shown on site) Web Site URL: (optional) Comment: (plain text only) Please Enter the following word:

Or E-Mail Uli privately.