Previous Next Contents Index Doc Set Home


Using Fix and Continue

7

Fixing allows you to quickly recompile edited source code without stopping the debugging process.

This chapter is organized into the following sections:

Basic Concepts

page 97

Fixing Your Program

page 99

Continuing after Fixing

page 99

Changing Variables after Fixing

page 100

Basic Concepts

The fix and continue feature allows you to modify and recompile a source file and continue executing without rebuilding the entire program. By updating the .o files and splicing them into your program, you don't need to relink.

The advantages of fixing and continuing are:

Note - Do not use fix if a build is in process; the output from the two processes will intermingle in the Building window.

How Fix and Continue Operate

The modified files are compiled and shared object (.so) files are created. Semantic tests are done by comparing the old and new files. The new object file is linked to your running process using the runtime linker. If the function on top of the stack is being fixed, the new stopped in function is the beginning of the same line in the new function. All the breakpoints in the old file are moved to the new file. The modified source replaces the old source in the editor window, and you can resume debugging from the exact point where you stopped.

Modifying Source Using Fix and Continue

You can modify source code in the following ways when using fix and continue:

Restrictions

WorkShop might have problems when functions are mapped from the old file to the new file. To minimize such problems when editing a source file:

If you need to make any of the proceeding changes, rebuild your program.

Fixing Your Program

To fix your file:

1. Save the changes to your source.

WorkShop automatically saves your changes if you forget this step.

2. Choose Execute Fix Changes or click the Fix icon on the tool bar.

The Build Output window opens and lets you know that your fix is underway. Any compile-time errors are listed and underscored, denoting links to source files.

Although you can do an unlimited number of fixes, if you have done several fixes in a row, consider rebuilding your program. Fixing changes the program image in memory, but not on the disk. As you do more fixes, the memory image gets out of sync with what is on the disk.

fix does not make the changes within your executable file, but only changes the .o files and the memory image. Once you have finished debugging a program, you need to rebuild your program to merge the changes into the executable.

For more information on customizing the Fix command, see Using Fix and Continue in the manual, Command-Line Utilities.

Continuing after Fixing

You can continue executing using Go, Step Into, or Start.

Before resuming program execution, you should be aware of the following conditions:

Changing an executed function
If you made changes in a function that has already executed, the changes will have no effect until:

If your modifications involve more than simple changes to variables, use Fix then Go. Using Go is faster than using Build because it does not relink the program.

Changing a function not yet called
If you made changes in a function not yet called, the changes will be in effect when that function is called.

Changing a function currently being executed
If you made changes to the function currently being executed, Fix's impact depends on where the change is relative to the stopped in function:

Changing a function presently on the stack
If you made changes to a function presently on the stack, but not the stopped in function, the changed code will not be used for the present call of that function. When the stopped in function returns, the old versions of the function on the stack execute.

There are two ways to solve this problem:

If there are breakpoints in modified functions on the stack, the breakpoints are moved to the new versions of the functions. If the old versions are executed, the program does not stop in those functions.

Changing Variables after Fixing

Changes made to global variables are not undone using Fix or by popping the stack. To manually reassign correct values to global variables, use the Data History pane of the Debugging window.

The following example shows how a simple bug can be fixed. The application gets a segmentation violation in line 6 when trying to dereference a NULL pointer:

	1	#include <stdio.h>

	2	

	3	char *from = "ships";

	4	void copy(char *to)

	5	{

	6		while ((*to++ = *from++) != '\0');

	7		*to = '\0';

	8	}

	9	

	10	main()

	11	{

	12		char buf[100];

	13	

	14		copy(0);

	15		printf("%s\n", buf);

	16		return 0;

	17	}



signal SEGV (no mapping at the fault address) in copy at line 6 
in

	file "testfix.cc"

	6		while ((*to++ = *from++) != '\0');

1. Change line 14 to copy to buf instead of 0 and save the file

2. Choose Execute Fix Changes.

modified line

	14		copy(buf);





fixing "testfix.cc".....

pc moved to "testfix.cc":6

stopped in copy at line 6 in file "testfix.cc"

	6		while ((*to++ = *from++) != '\0');







 










If the program is continued from here, it still gets a SEGV because the zero-pointer is still pushed on the stack. 







	3.	 Pop one frame of the stack by choosing Execute   Pop.







stopped in main at line 14 in file "testfix.cc"

	14		copy(buf); 







 










If the program is continued from here, it runs, but it will not contain the correct value because the global variable from has already been incremented by one. The program would print hips and not ships. 







	4.	 Use the Assign button in the Debugging window to restore the global variable.



	5.	 Click Go. 



Now the program prints the correct string:







ships







 















 



Previous


Next

Contents

Index

Doc Set

Home