Lập trình Wrox Professional Xcode 3 cho Mac OS part 61 ppsx

This happens when the execution of your program encounters a breakpoint, some exceptional event, or when you use the Pause command.. If the source line does not call another function, th

Showing the Type column is probably the fi rst thing I do after opening the debugger window for the fi rst time Alternatively, you can also Right/Control -click any variable and choose Show/Hide Type Column from the pop - up menu.

Sadly, Xcode doesn ’ t preserve this setting between Xcode sessions

There ’ s a lot more to examining data in the debugger This brief overview should give you some idea

of what you ’ re looking at while you progress to the more practical topic of controlling the debugger

and setting breakpoints Until you can stop your application, there ’ s no data to examine

CONTROLLING THE DEBUGGER

One of the most elementary, and often most effective, methods of debugging an application is

simply to stop it and examine its state Look at the value of local variables and objects, and see what

functions have been called and in what order You may then want to step through the code one line

at a time to witness its order of execution This, rather passive, method of debugging is often all

that ’ s required to determine what your code is doing wrong or unexpectedly

You control this kind of immediate and interactive debugging through a set of debugging

commands None of these commands (except the Pause command) is available until the debugger

has suspended your application This happens when the execution of your program encounters a

breakpoint, some exceptional event, or when you use the Pause command The most predictable

method is to set a breakpoint It ’ s possible to stop your program using the Debug ➪ Pause

command, but it ’ s rarely that useful Pause stops your program wherever it is at that moment —

usually in some framework or kernel call

Breakpoints can do many sophisticated things, and you can set them in a variety of ways, all of

which is covered later in the “ Breakpoints ” section For now, all you need to do is set and enable

simple breakpoints by clicking in the editor pane gutter of any source fi le A breakpoint appears as

a blue marker that indicates the position of the breakpoint in the source code Clicking an existing

breakpoint toggles its state between enabled (blue) and disabled (grey) Only enabled breakpoints

interrupt program execution To delete a breakpoint, drag the breakpoint out of the gutter or use

the Right/Control - click menu to select the Remove Breakpoint command

After the execution of your program has been suspended, a set of execution control commands

becomes available These are listed in the following table:

COMMAND SHORTCUT DESCRIPTION

Continue Option+Command+P Resumes execution of your program Your program

will run until it encounters another breakpoint or terminates

Pause Option+Command+P Immediately suspends execution of your program

This is the only command that will stop your program without setting a breakpoint

COMMAND SHORTCUT DESCRIPTION

Step Into Shift+Command+I Executes one line of source code If the line

contains a call to another function, execution is stopped again at the beginning of that function, which is what gives this command its name — you are stepping into the function being called If the source line does not call another function, this command is equivalent to Step Over

Step Over Shift+Command+O Executes one line of source code and stops before

executing the line that follows If the line contains calls to other functions, those functions are allowed

to execute in their entirety

Step Out Shift+Command+T Resumes execution until the current function

returns to its caller

Step Into Instruction

Option+Shift+Command+I Equivalent to Step Into, but steps through a single

machine instruction rather than a full line of source code, that might translate into dozens of machine instructions

Step Over Instruction

Option+Shift+Command+O Equivalent to Step Over, but steps over only a single

machine instruction

( continue to here )

Option+click in gutter Sets a temporary breakpoint and starts the program

running

Sync With Debugger

Returns the debugger window ’ s view to showing the current thread, current stack frame, current function, and current PC indicator where the debugger last suspended your process

Stop Shift+Command+Return Forcibly terminates your program ’ s process

Pause and Continue

The Pause and Continue commands are immediate and self - explanatory They share the same menu item, toolbar button, and keyboard shortcut The Pause command is active whenever the process is executing, and the Continue command is active whenever it is suspended

Generally, the Pause command isn ’ t very useful for working GUI applications, because it tends to suspend the application in a run loop You will probably fi nd it most edifying when your application is stuck in an endless, or seemingly endless, loop It can also be helpful to suspend your application while you think about your next move or contemplate where to set a breakpoint

You don ’ t have to stop the program to set a breakpoint, but you don ’ t necessarily want your application running amuck while you decide where it should go

Step Over and Into

Step Over and Step Into are the two most commonly used debugger control commands Step Over

lets you walk through the logic of a single function, ignoring the details of other functions that it

might call Step Into traces the execution of the program one step at a time, regardless of where that

leads

Step Into, Step Over, Continue to Here, and many other debugger commands work by setting temporary breakpoints A temporary breakpoint is one created

by the debugger for some ephemeral purpose, which it then deletes as soon as it ’ s reached For example, the Step Into command works by setting a temporary breakpoint at the beginning of the function that you want to step into It then lets the process execute Most of the time this works as expected.

You may, however, encounter unexpected behavior if the code encounters another breakpoint fi rst (possibly in another thread) or if there ’ s an exceptional event; the debugger will stop there instead

A different situation arises if a function exits abnormally (via a longjmp , by throwing an exception, or by terminating a thread) — the program may never execute the code wherein the temporary breakpoint was set In this situation, the program avoids the breakpoint and continues running indefi nitely

The Step Over command is intelligent about recursive functions Stepping over a function that calls

itself does not stop until all nested iterations of the function have executed and returned, even if that

entails executing the same code position that you are stepping over

If your editor pane is in disassembly view, Step Into and Step Over behave exactly the same way, but they each execute a single machine instruction — instead of the group of instructions generated by the single line of source code

If the source line contains multiple calls, the Step Into command steps into the fi rst function called

This is signifi cant if a function passes parameters that are obtained by calling other functions

The example in Listing 18 - 2 illustrates this If the debugger fi rst stopped at this line and you

issued the Step Into command, the debugger would step into getDefaultMode() , not setMode()

That ’ s because the getDefaultMode function is called fi rst to obtain the value of setMode ’ s single

argument

setMode(getDefaultMode()); // reset the mode

After you return from getDefaultMode (see the Step Out command), the debugger again returns to this line of source code, but the CPU ’ s program counter is now poised at the call to setMode This time the Step Into command steps into the setMode function

This is the situation where the hover step controls are exceptionally useful.

Hover your cursor over the function or method name you want to step into and click its step into button Xcode will step into that specifi c function, allowing any prerequisite functions to execute without interruption

Step Into only steps into functions that have debug information and have local source fi les associated with them You cannot step into library functions, framework APIs, or kernel code that was not compiled with full debug information Attempting to step into such a function is treated like a Step Over

Stepping Out

Step Out is convenient for letting the current function complete its execution and return again to the point where it was called It ’ s common to step into a function simply to examine the values of its arguments After you are satisfi ed the function is behaving correctly, you can then use Step Out

to let the function fi nish and return to where it was called The same issues about exceptional exits that apply to Step Over also apply here

Stepping Over and Into Single Instructions

The special Step Into Instruction and Step Over Instruction perform the same actions as the Step Into and Step Over, but each only executes a single machine instruction These functions work

in either source or disassembly view, but are most useful when you ’ re viewing both the source and disassembly of your program ’ s code where the meaning of Step Into and Step Over becomes ambiguous

Step Into Instruction is also away around the Step Into command ’ s self - imposed limitation of never stepping into a function that doesn ’ t have source information (like a library function) If the function being called has no source code available, Step Into Instruction still steps into it, automatically switching to a disassembly - only view, as required

Continue to Here

The continue to here command doesn ’ t appear in the menu and has no keyboard shortcut A continue to here button appears when you hover over an executable line number in the gutter You can also use this, much quicker, shortcut:

Option+click a line number in the gutter The continue to here action creates a temporary breakpoint and starts your application running, just

as if you had set a regular breakpoint and issued the Continue command A breakpoint indicator

is not visible in the gutter or anywhere else in Xcode, and the breakpoint is deleted as soon as it is

➤

hit This makes it extremely easy to skip through blocks of code or around loops by simply clicking

where you want to stop next The same caveats about temporary breakpoints mentioned earlier

apply here

THE MINI - DEBUGGER

The mini - debugger is a compact debugger control window that ’ s intended to be used in situations

where switching between your application and Xcode is awkward or impossible This is particularly

true of applications that present full - screen multimedia, games, animation, screen savers, and

similar environments

You open the mini - debugger with the Run ➪ Mini - Debugger (Control+Command+Home)

command It opens a small fl oating window, shown on the left in Figure 18 - 17 The mini - debugger

window fl oats above all other window layers, including the menubar, so it stays visible regardless of

what application you switch to or what other windows are displayed

FIGURE 18-17

While the application is running, the mini - debugger window has four buttons:

Stop Pause (De)activate Breakpoints Xcode

The stop, pause, and toggle breakpoints button each perform their respective action The Xcode

button simply returns you to the Xcode application — often handy in applications where all of the

Xcode windows and the menubar are obscured

Whenever the application is paused, the mini - debugger window expands to show a small editor

pane, as shown on the right in Figure 18 - 17 The pane has all of the in - editor debugger controls

described in the “ In - Editor Debugging ” section

➤

➤

➤

➤

If you like the mini - debugger, you ’ ll probably want to set the On Start Open Mini Debugger setting

in the debugging preferences pane

BREAKPOINTS

Breakpoints are locations in your program where you want the debugger to take control Formally,

a breakpoint is set at a particular address in memory When the CPU ’ s program counter matches the address of a breakpoint — that is to say at the instant before the instruction at that breakpoint ’ s address is to be executed — the CPU stops executing your program and passes control to the debugger

So far you ’ ve created only basic breakpoints The default action of a breakpoint is to halt the execution of your program, hand over control to the debugger, and wait for instructions, but breakpoints are capable of much more

Before getting into more advanced techniques for defi ning breakpoints, here ’ s a quick review of the methods for creating a basic breakpoint — one that simply stops the program when encountered:

Click in the gutter of a source fi le

Right/Control - click in the gutter of a source fi le and choose the Add Breakpoint command

Choose the Run ➪ Manage Breakpoints ➪ Add Breakpoint At Current Line (Command+\) command when the active text cursor is in a source fi le

Use any of the debugger commands to create a temporary breakpoint and start the program running

When you ’ re setting breakpoints graphically, Xcode allows you to set a breakpoint on just about any line of the source fi le A lot of times this doesn ’ t make any sense, but Xcode can ’ t tell that

When you set a breakpoint in a source fi le, you ’ re actually setting the breakpoint at the fi rst executable instruction produced by the source fi le at, or following, the line you clicked Figure 18 - 18 shows three breakpoints set in a source fi le All three of these breakpoints point to the same address location The fi rst one is set on a declaration statement that produces no code, and the second one is set on a completely blank line Only the source code on line 30 produces any executable code in the application Ultimately, you could set a breakpoint on line 28, 29, or 30 with the same results The breakpoint is set at the instruction that implements the switch statement

➤

➤

➤

➤

FIGURE 18-18