Step-by-step example for using GDB within Emacs to debug a C or C++ program
You can debug a C or C++ program using GDB, the GNU debugger, which was developed by the same organization that released Emacs. You can easily integrate it with Emacs to interactively debug programs. While you can use it from the Unix prompt, it has additional functionality when you use it within the Emacs editor.
Compile program with appropriate debugging flag(s)
Assume you have the following program, foo.c, that
is segfaulting:
To use GDB, first compile your program using the
-g option in cc or
gcc, for example:
Open GDB (within Emacs for added functionality)
- While editing
foo.cwithin Emacs, to start a separate window for the debugger and to load the executable, enter: M-x gdbWhen Emacs prompts you, enter:
gdb fooYou should get a
GNU gdb Red Hat Linux (6.0post-0.20040223.19rh) . . . (gdb)(gdb)prompt similar to what is shown below: - You can list source code using the
listcommand. (Thelistcommand with two comma-separated integer parameters will show code between those two line numbers, for example,list 1, 6). (gdb) list 1 #include <stdio.h> 2 3 int main () { . . . 9 return 0; 10 } - To investigate why the program is crashing, run the program first
using the
runcommand. Then you could try thewherecommand. It will show you a stack trace, with the source line number where each function in the stack was.Note: The
(gdb) run Starting program: foo Program received signal SIGSEGV, Segmentation fault. 0x009d4b47 in memset () from /lib/tls/libc.so.6 (gdb) where #0 0x009d4b47 in memset () from /lib/tls/libc.so.6 #1 0x00a870dc in nullserv () from /lib/tls/libc.so.6 #2 0x080483c6 in main () at foo.c:6 (gdb)runcommand will cause your source code to be loaded in a second window, one of the many advantages of using GDB within Emacs.In our simple case, it is obvious that the program crashed on the
memset()function call. - In real world programs with more complicated code, if the
wherecommand is not enough to isolate the problem, you'll need to do debugging at a more detailed level.For that, you may need to set break points at spots where you think the problem might be. In the example shown below, break points are set at line numbers 3, 4, and 6. Then the program is run once again, while stepping through each break point using the
(gdb) break 3 Breakpoint 1 at 0x80483a8: file foo.c, line 3. (gdb) break 4 Breakpoint 2 at 0x80483b8: file foo.c, line 4. (gdb) break 6 Breakpoint 3 at 0x80483b8: file foo.c, line 6. (gdb) (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: foo Breakpoint 1, main () at foo.c:3 (gdb) next Breakpoint 2, main () at foo.c:6 (gdb) next Program received signal SIGSEGV, Segmentation fault. 0x009d4b47 in memset () from /lib/tls/libc.so.6 (gdb)runand thenextcommands respectively:Given that our example was too simple in the first place, it should still be obvious that the call to
memset ()is what was causing the segfault. - Once you find the bug, you might want to kill the program (that
crashed halfway through) using the
killcommand: (gdb) kill Kill the program being debugged? (y or n) y (gdb) - You can get help within GDB using the
helpcommand; enteringhelpby itself will list a set of subtopics for which help is available: (gdb) help List of classes of commands: aliases -- Aliases of other commands . . . Type "help" followed by a class name for a list of commands in that class. Type "help" followed by command name for full documentation. Command name abbreviations are allowed if unambiguous. (gdb)Entering
(gdb) help running Running the program. List of commands: advance -- Continue the program up to the given location (same form as args for break command) attach -- Attach to a process or file outside of GDB . . . until -- Execute until the program reaches a source line greater than the current Type "help" followed by command name for full documentation. Command name abbreviations are allowed if unambiguous. (gdb)help topicwill show you more detailed information, for example:
This document was developed with support from the National Science Foundation (NSF) under Grant No. 0503697 to the University of Chicago and subcontracted to Indiana University. Additional support was provided by IU through its participation in the TeraGrid, which is supported by the NSF under Grants No. 0833618, SCI451237, SCI535258, and SCI504075. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF.
Also see:
- At IU, what C++ compilers are available on the UITS central systems?
- For Emacs, where can I get documentation?
- At IU, what C compilers are available on the UITS central systems?
- GNU Emacs Quick Reference Guide
- Where can I find help with Emacs?
- Within Emacs on Unix, how can I debug a C or C++ program?
- What are segmentation faults (segfaults), and how can I identify what's causing them?
Last modified on May 13, 2009.






