Most tricky/useful commands for gdb debugger
CUnixGdbDebuggingDbxC Problem Overview
Can you post your most tricky and useful commands while you run a debugger like gdb or dbx.
C Solutions
Solution 1 - C
- backtrace full: Complete backtrace with local variables
- up, down, frame: Move through frames
- watch: Suspend the process when a certain condition is met
- set print pretty on: Prints out prettily formatted C source code
- set logging on: Log debugging session to show to others for support
- set print array on: Pretty array printing
- finish: Continue till end of function
- enable and disable: Enable/disable breakpoints
- tbreak: Break once, and then remove the breakpoint
- where: Line number currently being executed
- info locals: View all local variables
- info args: View all function arguments
- list: view source
- rbreak: break on function matching regular expression
Solution 2 - C
Start gdb with a textual user interface
gdb -tui
Solution 3 - C
Starting in gdb 7.0, there is reversible debugging, so your new favourite commands are:
* reverse-continue ('rc') -- Continue program being debugged but run it in reverse
* reverse-finish -- Execute backward until just before the selected stack frame is called
* reverse-next ('rn') -- Step program backward, proceeding through subroutine calls.
* reverse-nexti ('rni') -- Step backward one instruction, but proceed through called subroutines.
* reverse-step ('rs') -- Step program backward until it reaches the beginning of a previous source line
* reverse-stepi -- Step backward exactly one instruction
* set exec-direction (forward/reverse) -- Set direction of execution.
Solution 4 - C
Instead of launching GDB with "-tui" param you can also switch to text mode after a while using by typing "wh".
Solution 5 - C
thread apply all bt or thread apply all print $pc: For finding out quickly what all threads are doing.
Solution 6 - C
For example the macros defined in stl-views.gdb
Solution 7 - C
Using the -command=<file with gdb commands> option while firing up gdb. Same as -x <command file>. This command file can contain gdb commands like breakpoints, options, etc. Useful in case a particular executable needs to be put through successive debug runs using gdb.
Solution 8 - C
scripting gdb is a good trick, other than that I like set scheduler locking on / off to prevent the running of other threads when you are stepping in one.
Solution 9 - C
-
Using .gdbinit (start up file where you can write macros and call from gdb). Place .gdbinit in your home directory so that it is picked up every time gdb is loaded
-
info threads to list all the active threads, and f(#) -> # thread number you want to switch to
-
sometime i use gdb to convert from hex to decimal or binary, its very handy instead of opening up a calculator
- p/d 0x10 -> gives decimal equivalent of 0x10
- p/t 0x10 -> binary equivalent of 0x10
- p/x 256 -> hex equivalent of 256
Solution 10 - C
Instead of starting gdb with the option -tui to see a child process that contains a screen that highlights where the executing line of code is in your program, jump in and out of this feature with C-x o and C-x a. This is useful if you're using the feature and what to temporarily not use it so you can use the up-arrow to get a previous command.
Solution 11 - C
This can be useful, I am sure it could be improved though, help welcome:
define mallocinfo
set $__f = fopen("/dev/tty", "w")
call malloc_info(0, $__f)
call fclose($__f)
Solution 12 - C
To debug STL, add content to .gdbinit, follow these instructions: