Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Studio 12.3: Debugging a Program With dbx Oracle Solaris Studio 12.3 Information Library |
4. Viewing and Navigating To Code
5. Controlling Program Execution
6. Setting Breakpoints and Traces
8. Evaluating and Displaying Data
11. Debugging Multithreaded Applications
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
Breakpoint Event Specifications
inmember function inmethod function
inclass classname [-recurse | -norecurse]
inobject object-expression [-recurse | -norecurse]
Data Change Event Specifications
access mode address-expression [, byte-size-expression]
dlopen [ lib-path ] dlclose [ lib-path ]
Execution Progress Event Specifications
Variables Valid for when Command
Variables Valid for when Command and Specific Events
Setting a Breakpoint for Store to an Array Member
Enabling a Handler While Within a Function (in function)
Determining the Number of Lines Executed
Determining the Number of Instructions Executed by a Source Line
Enabling a Breakpoint After an Event Occurs
Resetting Application Files for replay
An event specification modifier sets additional attributes of a handler, the most common kind being event filters. Modifiers must appear after the keyword portion of an event specification. A modifier begins with a dash (-). The following are the valid event specification modifiers.
The condition is evaluated when the event specified by the event specification occurs. The side effect of the handler is allowed only if the condition evaluates to nonzero.
If the -if modifier is used with an event that has an associated singular source location, such as in or at, condition is evaluated in the scope corresponding to that location. Otherwise, qualify it with the desired scope.
Macro expansion is performed on the condition according to same conventions as with the print command.
The -resumeone modifier can be used with the -if modifier in an event specification for a multithreaded program, and causes only one thread to be resumed if the condition contains function calls. For more information, see Using a Filter With a Conditional Event.
The event triggers only if it occurs between the time the first instruction of the given function is reached and the time the function returns. Recursion on the function are ignored.
The-disable modifier creates the handler in the disabled state.
The -count n and -count infinity modifiers have the handler count from 0 (see Using Event Counters). Each time the event occurs, the count is incremented until it reaches n. Once that happens, the handler fires and the counter is reset to zero.
Counts of all enabled handlers are reset when a program is run or rerun. More specifically, they are reset when the sync event occurs.
The count is reset when you begin debugging a new program with the debug -r command (see debug Command) or the attach -r command (see attach Command).
Creates a temporary handler. Once the event has occurred it is automatically deleted. By default, handlers are not temporary. If the handler is a counting handler, it is automatically deleted only when the count reaches 0 (zero).
Use the delete -temp command to delete all temporary handlers.
Makes the handler act at an instruction level. This event replaces the traditional ’i’ suffix of most commands. It usually modifies two aspects of the event handler:
Any message prints assembly-level rather than source-level information.
The granularity of the event becomes instruction level. For instance, step -instr implies instruction-level stepping.
The action is executed only if the thread that caused the event matches thread_id. The specific thread you have in mind might be assigned a different thread_id from one execution of the program to the next.
The action is executed only if the thread that caused the event matches lwp_id. The action is executed only if the thread that caused the event matches lwp_id. The specific thread you have in mind might be assigned a different lwp_id from one execution of the program to the next.
Hides the handler in a regular status command. Use status -h to see hidden handlers.
Normally all handlers are thrown away when a new program is loaded. Using the -perm modifier retains the handler across debugging sessions. A plain delete command does not delete a permanent handler. Use delete -p to delete a permanent handler.