JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Studio 12.3: Debugging a Program With dbx     Oracle Solaris Studio 12.3 Information Library
search filter icon
search icon

Document Information

Preface

1.  Getting Started With dbx

2.  Starting dbx

3.  Customizing dbx

4.  Viewing and Navigating To Code

5.  Controlling Program Execution

6.  Setting Breakpoints and Traces

7.  Using the Call Stack

8.  Evaluating and Displaying Data

9.  Using Runtime Checking

10.  Fixing and Continuing

Using Fix and Continue

How Fix and Continue Operates

Modifying Source Using Fix and Continue

Fixing Your Program

To Fix Your File

Continuing After Fixing

Changing an Executed Function

Changing a Function Not Yet Called

Changing a Function Currently Being Executed

Changing a Function Presently on the Stack

Changing Variables After Fixing

Modifying a Header File

Fixing C++ Template Definitions

11.  Debugging Multithreaded Applications

12.  Debugging Child Processes

13.  Debugging OpenMP Programs

14.  Working With Signals

15.  Debugging C++ With dbx

16.  Debugging Fortran Using dbx

17.  Debugging a Java Application With dbx

18.  Debugging at the Machine-Instruction Level

19.  Using dbx With the Korn Shell

20.  Debugging Shared Libraries

A.  Modifying a Program State

B.  Event Management

C.  Macros

D.  Command Reference

Index

Fixing Your Program

You can use the fix command to relink source files after you make changes, without recompiling the entire program. You can then continue execution of the program.

To Fix Your File

  1. Save the changes to your source.
  2. Type fix at the dbx prompt.

    Although you can do an unlimited number of fixes, if you have done several fixes in a row, consider rebuilding your program. The fix command 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.

    The fix command 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 must rebuild your program to merge the changes into the executable. When you quit debugging, a message reminds you to rebuild your program.

    If you invoke the fix command with an option other than -a and without a file name argument, only the current modified source file is fixed.

    When fix is invoked, the current working directory of the file that was current at the time of compilation is searched before executing the compilation line. There might be problems locating the correct directory due to a change in the file system structure from compilation time to debugging time. To avoid this problem, use the command pathmap, which creates a mapping from one path name to another. Mapping is applied to source paths and object file paths.

Continuing After Fixing

You can continue executing using the cont command (see cont Command).

Before resuming program execution, be aware of the following conditions that determine the effect of your changes.

Changing an Executed Function

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

If your modifications involve more than simple changes to variables, use the fix command, then the run command. Using the run command is faster because it does not relink the program.

Changing a Function Not Yet Called

If you have 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 have made changes to the function currently being executed, the impact of the fix command depends on where the change is relative to the stopped in function:

Changing a Function Presently on the Stack

If you have made changes to a function presently on the stack, but not to the stopped in function, the changed code is not used for the present call of that function. When the stopped in function returns, the old versions of the function on the stack are executed.

There are several 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.