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

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

Dynamic Linker

Link Map

Startup Sequence and .init Sections

Procedure Linkage Tables

Fix and Continue

Setting Breakpoints in Shared Libraries

Setting a Breakpoint in an Explicitly Loaded Library

A.  Modifying a Program State

B.  Event Management

C.  Command Reference

Index

Setting Breakpoints in Shared Libraries

To set a breakpoint in a shared library, dbx needs to know that a program will use that library when it runs, and dbx needs to load the symbol table for the library. To determine which libraries a newly-loaded program will use when it runs, dbx executes the program just long enough for the runtime linker to load all of the starting libraries. dbx then reads the list of loaded libraries and kills the process. The libraries remain loaded and you can set breakpoints in them before rerunning the program for debugging.

dbx follows the same procedure for loading the libraries whether the program is loaded from the command line with the dbx command, from the dbx prompt with the debug command, or in the IDE.