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


1.  Getting Started With dbx

2.  Starting dbx

Starting a Debugging Session

Debugging a Core File

Debugging a Core File in the Same Operating Environment

If Your Core File Is Truncated

Debugging a Mismatched Core File

Eliminating Shared Library Problems

Things to Remember

Using the Process ID

The dbx Startup Sequence

Setting Startup Properties

Mapping the Compile-time Directory to the Debug-time Directory

Setting dbx Environment Variables

Creating Your Own dbx Commands

Compiling a Program for Debugging

Compiling with the -g Option

Using a Separate Debug File

Creating a Separate Debug File

Debugging Optimized Code

Parameters and Variables

Inlined Functions

Code Compiled Without the -g Option

Shared Libraries Require the -g Option for Full dbx Support

Completely Stripped Programs

Quitting Debugging

Stopping a Process Execution

Detaching a Process From dbx

Killing a Program Without Terminating the Session

Saving and Restoring a Debugging Run

Using the save Command

Saving a Series of Debugging Runs as Checkpoints

Restoring a Saved Run

Saving and Restoring Using replay

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

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


Debugging Optimized Code

dbx provides partial debugging support for optimized code. The extent of the support depends largely upon how you compiled the program.

When analyzing optimized code, you can:

When programs are compiled with optimization and debugging enabled at the same time (using the -O and -g options), dbx operates in a restricted mode.

The details about which compilers emit which kind of symbolic information under what circumstances is considered an unstable interface and is likely to change from release to release.

Source line information is available, but the code for one source line might appear in several different places for an optimized program, so stepping through a program by source line results in the “current line” jumping around in the source file, depending on how the code was scheduled by the optimizer.

Tail call optimization can result in missing stack frames when the last effective operation in a function is a call to another function.

For OpenMP programs, compiling with the -xopenmp=noopt option instructs the compiler not to apply any optimizations. However, the optimizer still processes the code in order to implement the OpenMP directives, so some of the problems described might occur in programs compiled with -xopenmp=noopt.

Parameters and Variables

Generally, symbolic information for parameters, local variables, and global variables is available for optimized programs. Type information about structs, unions, C++ classes, and the types and names of local variables, global variables, and parameters should be available.

Information about the location of parameters and local variables is sometimes missing for optimized code. If dbx cannot locate a value, it reports that it cannot. Sometimes the value might disappear temporarily, so try to single-step and print again.

The Oracle Solaris Studio 12.2 compilers for SPARC based systems and x86 based systems provide the information for locating parameters and local variables. Newer versions of the GNU compilers also provide this information.

You can print global variables and assign values to them, although they might have inaccurate values if the final register-to-memory store has not happened yet.

Inlined Functions

dbx allows you to set breakpoints on inlined functions. Control stops at the first instruction from the inlined function in the caller. You can perform the same dbx operations (for example, step, next, and list commands) on inlined functions as you can perform on non-inlined functions.

The where command shows the call stack with the inlined function and the parameters if location information for the inlined parameters is available.

The up and down commands for moving up and down the call stack are also supported for inlined functions.

Local variables from the caller are not available in the inline frame.

Registers, if shown, are those from the caller's window.

Functions that the compilers might inline include the C++ inline functions, the C functions with the C99 inline keyword, and any other functions that the compiler deems profitable for performance.

The sections Inlining of Functions and Parallelization in Chapter 8 of the Performance Analyzer manual contain information that might be helpful when debugging an optimized program.

Code Compiled Without the -g Option

While most debugging support requires that a program be compiled with -g, dbx still provides the following level of support for code compiled without -g:

Note, however, that dbx cannot display source code unless the code was compiled with the -g option. This restriction also applies to code that has had strip -x applied to it.

Shared Libraries Require the -g Option for Full dbx Support

For full support, a shared library must also be compiled with the -g option. If you build a program with shared library modules that were not compiled with the -g option, you can still debug the program. However, full dbx support is not possible because the information was not generated for those library modules.

Completely Stripped Programs

dbx can debug programs that have been completely stripped. These programs contain some information that can be used to debug your program, but only externally visible functions are available. Some runtime checking works on stripped programs or load objects: memory use checking works, and access checking works with code stripped with strip -x but not with code stripped with strip.