Fixing the Code from within the Debugger

HP WDB lets you change the program you are debugging without having to exit the debugger or even restart the executable you are debugging. You have the option of explicitly requesting that a file be rebuilt and patched in, or you can have the debugger monitor source files, rebuilding the executable whenever changes are detected.




	NOTE: Changes made to an executable during a debugging session are not saved when you exit the debugger. To apply the changes outside the debugger, you must rebuild your executable. There are a number of restrictions on the changes you can make to your program while it is being debugged. See Restrictions on Fixing Code from within the Debugger for details.

Fixing code and continuing your program

To edit your source code in the debugger

On the File menu, click Open File.
In the Directories list, double-click to select the appropriate directory.
Select the Open in debugger toggle (this is the default).If you prefer, you can choose to open the file in an external editor.
Make changes to the source file or files.
If you’re using an external editor, save your changes when you have completed them.
Click on one of the following toolbar buttons:
- Step Into
- Step Over
- Step Out
- Step Last
- Go
- Restart
WDB GUI asks you if you want to apply the source changes. Click Yes. The debugger performs the command you selected using the modified source.

The Build View tab displays any build output and reports when the build has completed.




	NOTE: When the debugger starts an external editor, it chooses the editor based on the environment variable EDITOR. If EDITOR is not set, the debugger starts vi. Files you open are monitored for changes (text changes for the debugger editor; modification times for external editors). When you click on a program execution button (such as Step Into), the debugger asks you if you want to rebuild changed files. The fix and continue feature is not supported on IPF platform.

Explicitly requesting the debugger for monitoring or rebuilding files

You can explicitly request that the debugger monitor or fix a specific file or files. This is useful, for example, for building dependent files that need to be rebuilt because you change a header file.

To explicitly request for monitoring a specific file for changes

On the Edit menu, click Fix List.... The Add/Delete Fix List Files dialog appears.
Click Browse... to display the Name of File to Fix dialog box.
In the dialog box, choose a file to add to the fix list.
Click OK to close the dialog box. The file you selected appears in the Add/Delete Fix List Files dialog.
When you are finished adding files to the fix list, Click OK.All files in the list will be monitored for changes.

To request an immediate rebuild of a specific file

On the Edit menu, click Fix List.... The Add/Delete Fix List Files dialog box appears.
In the Fix List dialog, highlight any of the files in the fix list that you want rebuilt and patched in immediately.
Click OK in the Fix List dialog. The files you highlighted will be rebuilt and patched in immediately.

Examining build errors and warnings

Build errors and warnings are posted to the Build View. The debugger displays the Build View automatically when the debugger rebuilds code you have fixed.

To view the source code for an error or warning, double click on the error or warning in the Build View. The source associated with the error or warning will be displayed in the Source View.

Restrictions on fixing code from within the debugger

These types of source code changes cannot be fixed within the debugger:

Adding, deleting or reordering the local variables and parameters in a function currently active on the stack.
Changing the data type of a local variable, file static, global variable, parameter of a function.
Changing a local, file static, or global variable to be a register variable, or vice-versa.
Adding any function calls that increase the size of the parameter area.
Adding an alloca() function to a frame that did not previously use alloca().
Adding fields to a structure anywhere other than at the end of the structure.
Changing the order of fields in a structure.

Additionally, the debugger has these limitations in how it handles changed code:

With the exception of the routine at the top of the stack, new code will not be executed for a routine currently on the stack until that routine is popped off the stack and program execution reenters that routine.
With the exception of the routine at the top of the stack, breakpoints in a routine on the stack will be inactive until that routine is popped off the stack and program execution reenters that routine.
If the name of a function is changed and there was a breakpoint set to the old version of the function, the breakpoint is not moved to the new function. Additionally, the old breakpoint is still valid (and can be hit when existing routines call the old function name).
If the number of lines of the modified file is different from that of the original file, the placement of breakpoints may not be correct.
When the program resumes, the program counter is moved to the beginning of the same line in the modified function. It is possible that the program counter may be at the wrong line.