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
328 Debugging with GDB
Sometimes people give a few sketchy facts and ask, “Does this ring a bell?” Those bug
reports are useless, and we urge everyone to refuse to respond to them except to chide the
sender to report bugs properly.
To enable us to fix the bug, you should include all these things:
• The version of GDB. GDB announces it if you start with no arguments; you can also
print it at any time using show version.
Without this, we will not know whether there is any point in looking for the bug in the
current version of GDB.
• The type of machine you are using, and the operating system name and version number.
• What compiler (and its version) was used to compile the program you are debugging—
e.g. “HP92453-01 A.10.32.03 HP C Compiler”. Use the what command with the
pathname of the compile command (‘what /opt/ansic/bin/cc’, for example) to obtain
this information.
• The command arguments you gave the compiler to compile your example and observe
the bug. For example, did you use ‘-O’? To guarantee you will not omit something
important, list them all. A copy of the Makefile (or the output from make) is sufficient.
If we were to try to guess the arguments, we would probably guess wrong and then we
might not encounter the bug.
• A complete input script, and all necessary source files, that will reproduce the bug.
• A description of what behavior you observe that you believe is incorrect. For example,
“It gets a fatal signal.”
Of course, if the bug is that GDB gets a fatal signal, then we will certainly notice it.
But if the bug is incorrect output, we might not notice unless it is glaringly wrong.
You might as well not give us a chance to make a mistake.
Even if the problem you experience is a fatal signal, you should still say so explicitly.
Suppose something strange is going on, such as, your copy of GDB is out of synch, or
you have encountered a bug in the C library on your system. (This has happened!)
Your copy might crash and ours would not. If you told us to expect a crash, then when
ours fails to crash, we would know that the bug was not happening for us. If you had
not told us to expect a crash, then we would not be able to draw any conclusion from
our observations.
Here are some things that are not necessary:
• A description of the envelope of the bug.
Often people who encounter a bug spend a lot of time investigating which changes to
the input file will make the bug go away and which changes will not affect it.
This is often time consuming and not very useful, because the way we will find the
bug is by running a single example under the debugger with breakpoints, not by pure
deduction from a series of examples. We recommend that you save your time for
something else.
Of course, if you can find a simpler example to report instead of the original one, that
is a convenience for us. Errors in the output will be easier to spot, running under the
debugger will take less time, and so on.
However, simplification is not vital; if you do not want to do this, report the bug
anyway and send us the entire test case you used.