How do you use gdb?

Question

I decided to find out how our C/C+ *nix practitioners use the gdb debugger.

Here is what I typically use:

1. b - break filename.c:line #, function, filename.cpp:function, className::Member
2. n, c, s -- next continue step
3. gdb program name => set breakpoints ==> run [parameter list] (I do this to set break points before the program starts)
4. l - to list the surrounding source code.
5. attach processID 6 break [location]
6. gdb programName corefile.core (to examine why app crashed)
7. I also sometimes set breakpoint at exit function (break exit) to examine program stacks
8. info b to examine all the breakpoints
9. clear [breakpoints list ]

How do you use it?

Answer 1

See the user guide at http://sources.redhat.com/gdb/current/onlinedocs/gdb_toc.html.

Answer 2

gdb is not my speciality, but here is what i use:

• bt list a stack
• up, down moving in a stack
• until continue until a line with greater number than current is reached -- for exiting loops
• watch [expr] break the program when expr changes

... but mostly i use ddd as a frontend to gdb

Answer 3

Most useful gdb commands in my opinion (aside from all already listed):

• info threads - information about threads
• thread N - switch to thread N
• catch throw - break on any thrown exception. Useful when you caught the bug only after the stack unwound.
• printf,print - examine any and all expressions, printf accepts C-style formatting specifiers

Finally, if debugging over a slow link, the text UI might be of use. To use it, start gdb with the --tui command-line switch.

Answer 4

There are also a couple of uses that are not directly connected with debugging. For example it can be used for C expression evaluation:

(gdb) printf "%lu\n", (unsigned long)(-3L)
4294967293

Answer 5

Scripting is a nice GDB feature.

1. First you set a breakpoint, like: b someFunction\n.
2. Then you run command: commands\n. GDB will ask for commands for that breakpoint.
3. Common scenario is to print some value and then continue, so you will enter: p someVar\n continue\n.
4. To end the script press: Ctrl-D

After running program you will see your script executed occasionally when the breakpoint occurs.

Answer 6

Besides things that have already been posted i also use:

• a .gdbinit file for STL containers
• signal SIGNAL noprint nostop for some custom signals that are of no real interest when debugging
• C-Casts to dereference pointers
• catchpoints (catch throw, catch catch)
• condition for conditional break- and watchpoints
• rarely gdbserver for remote debugging
• gdb program coredump, for those embarassing segfaults ;)

PS: One reason i personally love gdb btw. is that it supports tab-completion for nearly everything (gdb commands, symbols in the symbol table, functions, memberfunctions etc.). This is a fairly good productivity boost in my opinion.

Answer 7

Type Ctrl-X Ctrl-A to open a simple window with source preview.

Answer 8

i use the gdb -tui switch for a great 'text user interface' (a kind of gui in text mode). It supports multiple windows and is generally much more friendly than using the 'list' command (since it shows the source in a sep window)

Answer 9

Some time ago I found cgdb:

http://cgdb.sourceforge.net/

This is a curses (color console) based frontend for gdb that made my life a lot happier when I was restricted to debugging in a console window.