Debugging with GDB (February 2008)
Table Of Contents
- Summary of GDB
- A Sample GDB Session
- Getting In and Out of GDB
- GDB Commands
- Running Programs Under GDB
- Stopping and Continuing
- Examining the Stack
- Examining Source Files
- Examining Data
- Using GDB with Different Languages
- Examining the Symbol Table
- Altering Execution
- GDB Files
- Specifying a Debugging Target
- HP-UX Configuration-Specific Information
- Summary of HP Enhancements to GDB
- HP-UX dependencies
- Supported Platforms and Modes
- HP-UX targets
- Support for Alternate root
- Specifying object file directories
- Fix and continue debugging
- Inline Support
- Debugging Macros
- Debugging Memory Problems
- When to suspect a memory leak
- Memory debugging restrictions
- Memory Debugging Methodologies
- Debugging Memory in Interactive Mode
- Debugging Memory in Batch Mode
- Debugging Memory Interactively After Attaching to a Running Process
- Configuring memory debugging settings
- Scenarios in memory debugging
- Stop when freeing unallocated or deallocated blocks
- Stop when freeing a block if bad writes occurred outside block boundary
- Stop when a specified block address is allocated or deallocated
- Scramble previous memory contents at malloc/free calls
- Detect dangling pointers and dangling blocks
- Detect in-block corruption of freed blocks
- Specify the amount of guard bytes for every block of allocated memory
- Comparison of Memory Debugging Commands in Interactive Mode and Batch Mode
- Heap Profiling
- Memory Checking Analysis for User Defined Memory Management Routines
- Commands to track the change in data segment value
- Thread Debugging Support
- Debugging MPI Programs
- Debugging multiple processes ( programs with fork and vfork calls)
- Debugging Core Files
- Printing the Execution Path Entries for the Current Frame or Thread
- Invoking GDB Before a Program Aborts
- Aborting a Command Line Call
- Instruction Level Stepping
- Enhanced support for watchpoints and breakpoints
- Debugging support for shared libraries
- Language support
- Enhanced Java Debugging Support
- Commands for Examining Java Virtual Machine(JVM) internals
- Support for stack traces in Java, C, and C++ programs
- Support for 64-bit Java, C, aC++ stack unwinding
- Enhanced support for C++ templates
- Support for __fpreg data type on IPF
- Support for _Complex variables in HP C
- Support for debugging namespaces
- Command for evaluating the address of an expression
- Viewing Wide Character Strings
- Support for output logging
- Getting information from a non-debug executable
- Debugging optimized code
- Visual Interface for WDB
- Starting and stopping Visual Interface for WDB
- Navigating the Visual Interface for WDB display
- Specifying foreground and background colors
- Using the X-window graphical interface
- Using the TUI mode
- Changing the size of the source or debugger pane
- Using commands to browse through source files
- Loading source files
- Editing source files
- Editing the command line and command-line history
- Saving the contents of a debugging session to a file
- Support for ddd
- Support for XDB commands
- GNU GDB Logging Commands
- Support for command line calls in a stripped executable
- Displaying the current block scope information
- Linux support
- The HP-UX Terminal User Interface
- XDB to WDB Transition Guide
- By-function lists of XDB commands and HP WDB equivalents
- Overall breakpoint commands
- XDB data formats and HP WDB equivalents
- XDB location syntax and HP WDB equivalents
- XDB special language operators and HP WDB equivalents
- XDB special variables and HP WDB equivalents
- XDB variable identifiers and HP WDB equivalents
- Alphabetical lists of XDB commands and HP WDB equivalents
- Controlling GDB
- Canned Sequences of Commands
- Using GDB under gnu Emacs
- GDB Annotations
- The gdb/mi Interface
- Function and purpose
- Notation and terminology
- gdb/mi Command Syntax
- gdb/mi compatibility with CLI
- gdb/mi output records
- gdb/mi command description format
- gdb/mi breakpoint table commands
- gdb/mi Data manipulation
- gdb/mi program control
- Miscellaneous GDB commands in gdb/mi
- gdb/mi Stack Manipulation Commands
- gdb/mi Symbol query commands
- gdb/mi Target Manipulation Commands
- gdb/mi thread commands
- gdb/mi tracepoint commands
- gdb/mi variable objects
- Reporting Bugs in GDB
- Installing GDB
- Index
46 Debugging with GDB
even though the test in a C for-loop is written before the body of the loop.
The until command appeared to step back to the beginning of the loop when
it advanced to this expression; however, it has not really gone to an earlier
statement—not in terms of the actual machine code.
until with no argument works by means of single instruction stepping, and
hence is slower than until with an argument.
until location
u location
Continue running your program until either the specified location is reached,
or the current stack frame returns. location is any of the forms of argument
acceptable to break (see Section 5.1.1 [Setting breakpoints], page 33). This form
of the command uses breakpoints, and hence is quicker than until without an
argument.
stepi
stepi arg
si Execute one machine instruction, then stop and return to the debugger.
It is often useful to do ‘display/i $pc’ when stepping by machine instructions.
This makes GDB automatically display the next instruction to be executed,
each time your program stops. See Section 8.6 [Automatic display], page 68.
An argument is a repeat count, as in step.
nexti
nexti arg
ni Execute one machine instruction, but if it is a function call, proceed until the
function returns.
An argument is a repeat count, as in next.
5.3 Signals
A signal is an asynchronous event that can happen in a program. The operating system
defines the possible kinds of signals, and gives each kind a name and a number. For example,
in Unix SIGINT is the signal a program gets when you type an interrupt character (often C-
c); SIGSEGV is the signal a program gets from referencing a place in memory far away from
all the areas in use; SIGALRM occurs when the alarm clock timer goes off (which happens
only if your program has requested an alarm).
Some signals, including SIGALRM, are a normal part of the functioning of your program.
Others, such as SIGSEGV, indicate errors; these signals are fatal (they kill your program
immediately) if the program has not specified in advance some other way to handle the
signal. SIGINT does not indicate an error in your program, but it is normally fatal so it can
carry out the purpose of the interrupt: to kill the program.
GDB has the ability to detect any occurrence of a signal in your program. You can tell
GDB in advance what to do for each kind of signal.
Normally, GDB is set up to ignore non-erroneous signals like SIGALRM (so as not to
interfere with their role in the functioning of your program) but to stop your program