This chapter shows you how to start the Fix and Continue utility, explains pertinent concepts, and presents an overview of its command-line and graphical user interface.
 | Note: In Chapters 2 through 4, the word function means a C function or a C++ member or nonmember function. |
This chapter contains the following sections:
Fix and Continue is integrated with the CASEVision/WorkShop Debugger, cvd. To start the Debugger from a shell command line, use the following syntax:
cvd [-pid pid] [-host host] [executable [corefile]] [&]
You can specify the executable from the Debugger and by default the host is local, so all you really need to enter is cvd.
You issue Fix and Continue commands graphically from the Fix+Continue pulldown menu of the Debugger main window. You may also issue Fix and Continue commands from the Debugger command line (cvd>).
Fix and Continue gives you the ability to make changes to a program you are debugging without having to recompile and link the entire program, and then continue debugging the code. With Fix and Continue, you can edit a function, parse the new function, and continue execution of the program being debugged. Fix and Continue enables you to speed up your development cycle significantly.
Table 2-1 compares the cycle time in seconds between a full rebuild and a Fix and Continue for three typical programs.
Table 2-1. Fix and Continue Compile Time Cycle
Example | Time to Rebuild | Time to Fix+Continue |
|---|---|---|
Program A | 0:06 | 0:02 |
Program B | 0:33 | 0:06 |
Program C | 5:24 | 0:49 |
Redefine existing function definitions
Disable, re-enable, save, and delete redefinitions
Set breakpoints in and single-step within redefined code
View the status of changes
Examine differences between original and redefined functions
The basic cycle of using Fix and Continue is shown in Figure 2-1.
A typical session would be the following:
Using the Fix and Continue commands, you redefine a function. When you continue executing the program, the Debugger attempts to call the redefined function. If it cannot, an information popup appears, and the redefined function will be executed the next time the program calls that function.
You redefine other functions, alternating between debugging, disabling, re-enabling, and deleting redefinitions. You might save function redefinitions to their own files, or save files to a different name, to be used later with the present or with other programs.
Frequently during debugging you can review the status of changes by listing them, showing specific changes, or looking at the Fix and Continue Status View. You can compare changes to an individual function or to an entire file with the compiled versions. When satisfied with the behavior of your application, you save the file, replacing the compiled source.
Using Fix and Continue affects these WorkShop tools:
The WorkShop Debugger Main View, the Source View, and the Fix and Continue Status window make a clear distinction between compiled and redefined code, and allow editing only in redefined code.
The different WorkShop views that are knowledgeable about redefined code:
Call Stack
Trap Manager
Debugger command-line
Redefined functions have an identification number and special line numbers, and in the Debugger views, are color-coded.
Line numbers in the compiled file stay the same, no matter how redefined functions change. However, when you begin editing a function, the line numbers of the function body are represented in decimal notation (n.1, n.2, ..., n.m). n is the compiled line number where the function body begins. m is the line number relative to the beginning of the function body, starting with 1.
Figure 2-2 shows two redefined functions. Function 1 replaces lines 8-15. Function 2 replaces lines 18-20. Although its three lines are now one, the following line number is still 21.
The Call Stack and Trap Manager both use function-relative decimal notation when referring to a line number within the body of a redefined function.
The Debugger command line reports ongoing status. In addition to providing the same commands available from the menu, edit commands allow you to add, replace, or delete lines from files. You can easily operate on several files at once.
Fix and Continue has the following restrictions when you fix a function in which you have stopped:
You may not add, delete, or reorder the local variables in a function.
You may not change the type of a local variable.
You may not change a local variable to be a register variable, and vice- versa.
You may not add any function calls that increase the size of the parameter area.
You may not add an alloca function to a frame that did not previously use an alloca.
Both the old and new functions must be compiled with -g.
In other words, the layout of the stack frames of both the old and new functions must be identical for you to continue execution in the function that is being modified. If not, execution of the old function continues, and the new function is executed the next time it is called.
If you redefine functions which are in but not on top of the call stack, the modified code will not be executed when they combine. Modified functions will be executed only on their next call or on a re-run.
For example, consider the following call stack:
foo() bar() foobar() main()
If you redefine foo(), you can continue execution provided the layout of the stack frames are same.
If you redefine bar() [or foobar()], the new code will not be executed when foo() returns. The code will be executed only on the next call of bar() [or foobar()].
If you redefine main() after you have run, it will be executed only when you re-run.
The interface to Fix and Continue is through the Fix+Continue menu and its associated windows: Status, Message, and Build Environment. These windows are completely dependent on Fix and Continue, and do not operate unless it is installed.
For more complete information on all of the Fix and Continue menus, windows, and functions, see Chapter 4, “Fix and Continue Reference.”
Without Fix and Continue, the Debugger source views are Read-Only by default. That is so you can examine your files with no risk of changing them. When you select “Edit” from the Fix+Continue menu, the Debugger source code status indicator (in the lower-right corner of the Debugger window—see Figure 4-20) remains Read-Only. Fix and Continue edits are saved in an intermediate state and must be explicitly written with the “Save File+Fixes As...” option to be saved.
When you edit a function, it is color-highlighted. Then, if you switch to the compiled version, the color changes to show that there is a redefinition. If you try to edit the compiled version, the Debugger beeps, indicating it is Read-Only.
When you have completed your edits and wish to see the results, click “Parse and Load.” When the Parse and Load has executed successfully, the color changes again. If the color doesn't change, there may be errors, and you should check your “Message Window...” view.
Just as you can enter any dbx command at the Debugger command line, you can enter Fix and Continue commands there.
The Fix and Continue methods for accessing functions through ID numbers, finding files, and so forth, are discussed below.
Each redefined function is numbered with a change ID. Its status is redefined, enabled, disabled, deleted, or detached.
Fix and Continue needs to know where to find include files and other parameters specified by compiler build flags (compiler options). You can set the build environment for all files or for a specific file. You can display the current build environment from the Fix+Continue pulldown menu, the command line, or the Fix and Continue Status Window. When you finish a Fix and Continue session, you can unset the build environment.