Here I'll list things that are not found in the "Grand Unified Debugger" which comes with emacs
Table of Contents
- Multiple Debug Sessions
- Attaching to an existing debugger session in a comint-shell
- Switching between debuggers in a command shell, e.g. gdb and ruby
- Seeing where you previously stopped and moving back
- Single keystroke debugger commands inside the source code
- More Debuggers Available
- Facility to add more debuggers
Multiple Debug Sessions
GUD uses global variables to store last position seen in a debugger. Some key bindings are also globally assigned to a particular kind of debugger. As a result, you can have only one debug session going at a time. Perhaps some don't find this a limitation. But then, those are probably the people who aren't bothered by having to edit only one file at a time such as you have to do in vim.
Instead, we store debugger state inside the process buffer associated with the debugger. As a result, you can have several debugger sessions each using its talking to different kinds of debuggers. Key binds are buffer specific.
Attaching to an existing debugger session in a comint-shell
Sometimes inside a shell you may start or attach a debugger. For example inside
$ bashdb /etc/profile bash debugger, bashdb, release 4.2-0.8 Copyright 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2010, 2011 Rocky Bernstein This is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. (/etc/profile:4): 4: if [ "$PS1" ]; then bashdb<1>
At this point you may want to turn on tracking what's going on with emacs buffers so you can see track changes source code as code progresses. Simply run
M-x realgud-track-mode. The first time you will be prompted for a name of a debugger. If you want to change the debugger later, use
M-x dbgr-track-set-debugger. If you want to temporarily disable tracking debugging use
Switching between debuggers in a command shell, e.g. gdb and ruby-debug
Sometimes you may want to switch between debuggers possibly because your program can be debugged in several levels. For example if you are using ruby-debug to debug your Ruby program and you need to switch to gdb to debug at a lower level, that can be done.
Inside the command buffer sell, you can switch debugger using
M-x realgud-track-set-debugger. You'll be prompted for a debugger name.
Seeing where you previously stopped and moving back
As you step along in the program where you have previously stopped is recorded in a history ring. You can see in faded fringe arrows where you have previously been. Use
M-down to back and forth to the prior stopping points.
Single keystroke debugger commands inside the source code
When tracking the stopped position, the source buffer by default is in a minor mode that allows single keystrokes to issue debugger commands. For example, hitting the space bar steps the program, while the "u" key move move up a stack frame. In contrast to edebug where you can't change the source code while you are running it, here you can. You toggle the read-only mode and make our changes. Some locations may shift around, but since prior positions are also recorded as marks those positions should move around to the extent that GNU emacs tracks marks properly.
More Debuggers Available
There are about 24 or debuggers that are currently available in contrast to gud's 7 or so. See Debuggers-Supported for a list. Some debuggers are maintained as separate projects.
Many of the debuggers we support are more recent than those in gud and thus they are the only Emacs front-end to those debuggers. Some of gud's debuggers are pretty obscure such as those for sdb, xdb and jdb.
If there are several debuggers for a given programming-language interpreter, they share common programming-language code.
Facility to add more debuggers
I've tried to modularize and segregate specific debugger code. Each debugger lives in its own directory and most of the customization is relegated to a few files which are heavily commented. See How-to-add-a-new-debugger for details.
Customizing regular expressions can be tough. However, the existing debuggers have test code for the regular expressions. Modifying these tests for other debuggers helps making sure the modifications are what you want.