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:

  #include <stdio.h>

  int main () {
    int foo[5], n;

    memset((char *)0x0, 1, 100);

    printf (" Initial value of n is %d \n", n);
    return 0;
  }

To use GDB, first compile your program using the -g option in cc or gcc, for example:

  gcc -g -o foo foo.c

Open GDB (within Emacs for added functionality)

  1. While editing foo.c within Emacs, to start a separate window for the debugger and to load the executable, enter:
      M-x gdb

    When Emacs prompts you, enter:

      gdb foo

    You should get a (gdb) prompt similar to this:

      GNU gdb Red Hat Linux (6.0post-0.20040223.19rh)
       . . .
      (gdb) 
  2. You can list source code using the list command. (The list command 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	  }
  3. To investigate why the program is crashing, run the program first using the run command. Then, you could try the where command. It will show you a stack trace, with the source line number where each function in the stack was.

    Note: The run command will cause your source code to be loaded in a second window, one of the many advantages of using GDB within Emacs.

      (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) 

    In this simple case, it is obvious that the program crashed on the memset() function call.

  4. In real world programs with more complicated code, if the where command 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 run and next commands respectively:

      (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) 

    Given that the example was too simple in the first place, it should still be obvious that the call to memset () is what was causing the segfault.

  5. Once you find the bug, you might want to kill the program (that crashed halfway through) using the kill command:
      (gdb) kill
      Kill the program being debugged? (y or n) y
      (gdb)
  6. You can get help within GDB using the help command; entering help by 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 help topic will show you more detailed information, for example:

      (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) 

This document was developed with support from National Science Foundation (NSF) grants 1053575 and 1548562. Any opinions, findings, conclusions, or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF.

This is document aqsy in the Knowledge Base.
Last modified on 2016-11-30 12:37:21.

  • Fill out this form to submit your issue to the UITS Support Center.
  • Please note that you must be affiliated with Indiana University to receive support.
  • All fields are required.

Please provide your IU email address. If you currently have a problem receiving email at your IU account, enter an alternate email address.

  • Fill out this form to submit your comment to the IU Knowledge Base.
  • If you are affiliated with Indiana University and need help with a computing problem, please use the I need help with a computing problem section above, or contact your campus Support Center.

Please provide your IU email address. If you currently have a problem receiving email at your IU account, enter an alternate email address.