Difference between revisions of "Tip 9: gdb"
(Created page with 'The GNU Debugger (gdb) is extremely useful as a quick way to find problems in codes. I also like it because it is available on MANY platforms. If it is not on your current platfo…') |
|||
| Line 2: | Line 2: | ||
gdb can be run in three ways: | gdb can be run in three ways: | ||
| − | 1) gdb program | + | 1) |
| + | gdb program | ||
(or gdb --args program -my -program -argument) | (or gdb --args program -my -program -argument) | ||
will load your program and give a gdb prompt. | will load your program and give a gdb prompt. | ||
| − | 2) gdb program core | + | 2) |
| + | gdb program core | ||
will run your program using the state saved in a core dump. | will run your program using the state saved in a core dump. | ||
| − | 3) gdb program pid | + | 3) |
| + | gdb program pid | ||
will attach gdb to an already running program. (There are various ways to attach gdb over a network for embedded processors too...) | will attach gdb to an already running program. (There are various ways to attach gdb over a network for embedded processors too...) | ||
Once gdb is running, you have a prompt: | Once gdb is running, you have a prompt: | ||
| − | (gdb) | + | (gdb) |
at which you can tell it to run: | at which you can tell it to run: | ||
| − | (gdb) run | + | (gdb) run |
At any time, you can press Ctrl-C to interrupt and return to the debug prompt. Once there, you can single step into functions ("step" or just "s") or go to the next instruction ("next" or "n"). If you want to keep running, you can type "cont" or "c". | At any time, you can press Ctrl-C to interrupt and return to the debug prompt. Once there, you can single step into functions ("step" or just "s") or go to the next instruction ("next" or "n"). If you want to keep running, you can type "cont" or "c". | ||
| Line 20: | Line 23: | ||
If your program experiences a signal (segfault, bus error, fork, etc), it will return to the prompt. At this point, you want to investigate why the signal happened. The call stack is useful for this: | If your program experiences a signal (segfault, bus error, fork, etc), it will return to the prompt. At this point, you want to investigate why the signal happened. The call stack is useful for this: | ||
| + | Program received signal SIGABRT, Aborted. | ||
| + | 0x0000003977230265 in raise () from /lib64/libc.so.6 | ||
| + | (gdb) bt | ||
| + | #0 0x0000003977230265 in raise () from /lib64/libc.so.6 | ||
| + | #1 0x0000003977231d10 in abort () from /lib64/libc.so.6 | ||
| + | #2 0x00000039772296e6 in __assert_fail () from /lib64/libc.so.6 | ||
| + | #3 0x0000000000453276 in mrg_assert (test=false, msg= | ||
| + | {static npos = 18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7fff8732a380 "?? \003"}}) at global.C:770 | ||
| + | ... | ||
| + | #11 0x000000000047a94e in main (argc=6, argv=0x7fff8732ad68) at main.C:53 | ||
| + | (gdb) | ||
Revision as of 23:32, 4 May 2010
The GNU Debugger (gdb) is extremely useful as a quick way to find problems in codes. I also like it because it is available on MANY platforms. If it is not on your current platform, it is probably easily available as a pre-built package. Here is a quick start guide to the most useful features. More is available in various tutorials and the man page. You can abbreviate almost any gdb command by typing just enough characters to provide a unique match. Tab completion also works.
gdb can be run in three ways: 1)
gdb program
(or gdb --args program -my -program -argument) will load your program and give a gdb prompt. 2)
gdb program core
will run your program using the state saved in a core dump. 3)
gdb program pid
will attach gdb to an already running program. (There are various ways to attach gdb over a network for embedded processors too...)
Once gdb is running, you have a prompt:
(gdb)
at which you can tell it to run:
(gdb) run
At any time, you can press Ctrl-C to interrupt and return to the debug prompt. Once there, you can single step into functions ("step" or just "s") or go to the next instruction ("next" or "n"). If you want to keep running, you can type "cont" or "c".
Also at the prompt, you may want to see where you are at in the program. To see the current code, you can type "list" or to see the current call stack you can type "backtrace" (or "bt").
If your program experiences a signal (segfault, bus error, fork, etc), it will return to the prompt. At this point, you want to investigate why the signal happened. The call stack is useful for this:
Program received signal SIGABRT, Aborted.
0x0000003977230265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003977230265 in raise () from /lib64/libc.so.6
#1 0x0000003977231d10 in abort () from /lib64/libc.so.6
#2 0x00000039772296e6 in __assert_fail () from /lib64/libc.so.6
#3 0x0000000000453276 in mrg_assert (test=false, msg=
{static npos = 18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7fff8732a380 "?? \003"}}) at global.C:770
...
#11 0x000000000047a94e in main (argc=6, argv=0x7fff8732ad68) at main.C:53 (gdb)
