JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Studio 12.2: Debugging a Program With dbx
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.  Command Reference

Index

Using Fix and Continue

The fix and continue feature lets you modify and recompile a native 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 using fix and continue are:

How Fix and Continue Operates

Before using the fix command you must edit the source. (See Modifying Source Using Fix and Continue for the ways you can modify your code). After saving changes, type fix. For information on the fix command, see fix Command.

Once you have invoked the fix command, dbx calls the compiler with the appropriate compiler options. 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.

You can use fix and continue on files that have been compiled with or without debugging information, but there are some limitations in the functionality of the fix command and the cont command for files originally compiled without debugging information. See the -g option description in fix Command for more information.

You can fix shared objects (.so) files, but they must be opened in a special mode. You can use either RTLD_NOW|RTLD_GLOBAL or RTLD_LAZY|RTLD_GLOBAL in the call to the dlopen function.

The pre-compiled headers feature of the Oracle Solaris Studio C and C++ compilers requires that the compiler options be the same when recompiling. Because the fix command changes the compiler options slightly, do not use the fix command on object files that were created using precompiled headers.

Modifying Source Using Fix and Continue

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

Problems can occur when functions are mapped from the old file to the new file. To minimize such problems when editing a source file:

If you make any of the above changes, rebuild your entire program rather than using fix and continue.