The process of debugging usually entails alternating between times when your program has control, and times when Turbo Debugger has control.
When the debugger has control, you can use its features to search through your program's source code and data structures, looking for where things have gone wrong. However, when your program has control, you can't access the debugger's menus and windows; you must pause your program's execution and allow the debugger to regain control. (TD32's Wait for Child command, explained on page 28, is an exception to this rule.)
Using the debugger's execution control mechanisms, you can specify when and where you want the execution of your program to pause. Turbo
The Run menu
Run
Go to Cursor
Trace Into
Debugger offers the following mechanisms to control your program's execution:
• "Single Step" through machine instructions or source lines.
• Step over calls to functions.
• Run to a specified program location.
• Execute until the current function returns to its caller .
• " Animate" (perform continuous single stepping).
• Reverse program execution.
• Run until a breakpoint is encountered.
• Run until a specific Windows message is encountered.
• Pause when a C++ or C exception is thrown.
Except for breakpoints, Windows messages, and C++ exceptions, all execution control mechanisms are located on the Run menu.
The Run menu has a number of options for executing different parts of your program. Since these commands are frequently used, most are linked to function keys.
The Run command runs your program at full speed. Control returns to Turbo Debugger when one of the following events occurs:
• Your program terminates.
• A breakpoint with a break action is encountered.
• You interrupt execution with the program interrupt key.
• A program error halts execution.
• A
c++ or C exception that you have marked is thrown.The Go to Cursor command executes your program up to the line
containing the cursor in the current Module window or CPU Code pane. If the current window is a Module window, the cursor must be on aline of source code.
Known as single stepping, this command executes a single source line or assembly-level instruction at a time.
If the current window is a Module window, a single line of source code is executed; if it's a CPU window, a single machine instruction is executed. If the current source line contains a function call, Turbo Debugger traces into the function, providing that it was compiled with debug information. If the
Chapter 2, Starting Turbo Debugger and running your program 25
Step Over
Execute To
Until Return
current window is a CPU window, pressing F7 on a CALL instruction steps to the called routine.
When you single step through machine instructions (using Trace Into in the CPU wmdow or by pressing Alt+F7), Turbo Debugger treats certain sets of machine instructions as a single instruction. This causes multiple assembly instructions to be executed, even though you're single stepping through the code.
\ Here is a list of the machine instructions that cause multiple instructions to be executed when you are single stepping at the instruction level:
CALL INT LOOP
LOOPNZ LOOPZ
Also stepped over are REP, REPNZ, or REPZ followed by CMPS, CMPS, CMPSW, LOOSB, LOOSW, MOVS, MOVSB, MOVSW, SCAS, SCASB, SCASW, STOS, STOSB, or STOSW.
Turbo Debugger treats a class member function just like any other function;
F7 traces into the source code if it's available.
The Step Over command,like the Trace Into command, executes a single line of source code or machine instruction at a time. However, if you issue the Step Over command when the instruction pointer is located at a function call, Turbo Debugger executes that function at full speed, and places you at the statement following the function call.
When you step over a source line that contains multiple statements, Turbo Debugger treats any function calls in that line as part of the line-you don't end up at the start of one of the functions. If the line contains a return statement, Turbo Debugger returns you to the previously called routine.
The Run I Step Over command treats a call to a class member function like a single statement, and steps over it like any other function call.
Executes your program until the address you specify in the Enter Code Address to Execute To dialog box is reached. The address you specify might never be reached if a breakpoint action is encountered first, or if you interrupt execution.
Executes your program until the current function returns to its caller. This is useful in two circumstances: when you've accidentally single stepped into a ftinction that you don't need to debug, or when you've determined
Animate
that the current procedure works to your satisfaction, and you don't want to slowly step through the rest of it.
Performs a continuous series of Trace Into commands, updating the screen after each one. The animate command lets you watch your program's execution in "slow motion," and see the values of variables as they change. ' Press any key to interrupt this command.
After you choose Run I Animate, Turbo Debugger prompts you for a time delay between successive traces. The time delay is measured in tenths of a second; the default is 3.
If you are tracing through your program using F7 or Alt+F7, you can use Back Trace to reverse the direction of program execution. Reverse execution is handy if you trace beyond the point where you think there might be a bug, and you want to return to that point. .
Using the Back Trace command, you can back-trace a single step at a time or back-trace to a specified point that's highlighted in the Execution History window. Although reverse execution is always available in the CPU window, you can execute source code in reverse only if Full History is turned On in the Execution History window.
The Instruction Trace command executes a single machine instruction. Use this command when you want to trace into an interrupt, or when you're in a Module window and you want to trace into a procedure or function that doesn't contain debug information (for example, a library routine).
Since you will no longer be at the start of a source line, issuing this command usually places you inside a CPU window.
Use the Arguments command to set or change the command-line arguments supplied to the program you're debugging. Enter new arguments exactly as you would following the name of your program on the command line.
Once you've entered the arguments, Turbo Debugger asks if you want to reload your program from disk. You should answer "Yes" because most programs read the argument list only when the program is first loaded.
The Program Reset command terminates the program you're running and reloads it from disk. You might use this command in the following circumstances:
Chapter 2, Starting Turbo Debugger and running your program 27
Next Pending Status
Wait for Child
• When you've executed past the place where you think there is a bug.
• When your program has terminated and you want to run it again.
• If you've suspended your application with the program interrupt key, and you want restart it from the beginning. Make sure, however, that you don't interrupt the execution of your program within Windows kernel code.
• If you want to debug a DLL that's already been loaded. To do so, set the Debug Startup option in the Load Module Source or DLL Symbols dialog box to Yes for the DLL you're interested in, and reset your program.
If you choose the Program Reset command while you're in a Module or CPU window, the Turbo Debugger resets the Instruction Pointer to the beginning of the program. However, the display is not changed from the location where you issued the Program Reset command. This behavior makes it easy for you to resume debugging from the position you were a.t prior to issuing the Program Reset command.
For example, if you chose Program Reset because you executed a few statements past a bug, press Ctrl+F2 to rest your program and reposition the cursor up a few lines in your source file. Pressing F4 will then run to that location.
The Next Pending Status command (available when you're debugging with Windows NT) can be used when the Run I Wait for Child command is set to
No. When Wait for Child is set to No (and your program is running in the background while you're accessing Turbo Debugger), you can use the Next Pending Status command to retrieve a program status message. To indicate that a status message has been sent, Turbo Debugger's activity indicator displays PENDING. Status messages are sent on the occurrence of events such as breakpoints and exceptions.
Wait for Child (used exclusively by TD32 for debugging Windows NT programs) can be toggled to either Yes or No. When this option is set to No, you can access Turbo Debugger while your program is running; you don't have to wait for your program to hit a breakpoint or exception to access the debugger's views and menus.
This command can be useful when you're debugging interactive programs.
For example, if your program reads a lot of information from the keyboard, you can access the debugger while the program is waiting for input. You can set breakpoints and examine your program's data, even though your program has focus. Use the Refresh option in TD32INST to set the rate that TD32 updates the information in its windows.
Interrupting program execution
Stopping in Windows code
If your program is running, you can access Turbo Debugger by pressing the program interrupt key. The program interrupt key you use depends on the type of application you're debugging:
• Use Ctr/+AIt+SysRq when you're debugging a Windows 3.x program.
• Use Ctr/+AIt+F11 when you're debugging a Windows 32s program.
• Use F12 when you're debugging a Windows NT program.
• Use Ctr/+Break when you're debugging a DOS program.
Interrupting program execution is useful when you need to access Turbo Debugger, but haven't set any breakpoints that will interrupt your program's execution.
For example, if you single-step through a Windows application, you'll eventually get caught in the message loop, waiting for a message to be sent to your program. When this happens, you must press F9 to run the' program past the message loop. Once the program is running, you can press the program interrupt key to return to Turbo Debugger.
If, when you return to Turbo Debugger, you see a CPU window without any instructions corresponding to your program, you're probably in Windows kernel code. If this happens, return to Turbo Debugger and set a breakpoint at a location you know your program will execute. Next, run your program (F9) until it encounters the breakpoint. You are now out of Windows code, and can resume debugging your program.
Even though you can access the Module window, set breakpoints, and do other things inside Turbo Debugger, there are a few things that you should not do while you're stopped in Windows code:
• Don't single-step through your program. Attempting to single-step through Windows kernel code can produce unpredictable effects . . • Don't terminate or reload your application or Turbo Debugger-this
might cause a system crash.
If you attempt to reload your application, Turbo Debugger displays a prompt asking if you want to continue. Select No to return to Turbo Debugger.
Chapter 2, Starting Turbo Debugger and running your program 29