We recommend using the GUI front-end for GDB provided by Emacs. With
it, you can start GDB by typing "M-x gdb RET". This will suggest the
-default binary to debug; if you are going to start a new Emacs
-process, change it as needed to point to the correct binary.
-Alternatively, if you want to attach the debugger to an already
-running Emacs process, change the GDB command shown in the minibuffer
-to say this:
+file name of the default binary to debug; if the suggested default is
+not the Emacs binary you want to debug, change the file name as
+needed. Alternatively, if you want to attach the debugger to an
+already running Emacs process, change the GDB command shown in the
+minibuffer to say this:
gdb -i=mi -p PID
"--enable-check-lisp-object-type" option at configure time) that are
hard to interpret, especially if they represent long lists. You can
use the 'pp' command to display them in their Lisp form. That command
-displays its output on the standard error stream (on GNU/Linux, you
-can redirect that to a file using "M-x redirect-debugging-output").
+displays its output on the standard error stream, which you
+can redirect to a file using "M-x redirect-debugging-output".
This means that if you attach GDB to a running Emacs that was invoked
from a desktop icon, chances are you will not see the output at all,
or it will wind up in an obscure place (check the documentation of
These commands send their output to stderr; if that is closed or
redirected to some file you don't know, you won't see their output.
This is particularly so for Emacs invoked on MS-Windows from the
-desktop shortcut. On GNU/Linux, you can use the command
-'redirect-debugging-output' to redirect stderr to a file.
+desktop shortcut. You can use the command 'redirect-debugging-output'
+to redirect stderr to a file.
Note: It is not a good idea to try 'pr', 'pp', or 'pv' if you know that Emacs
is in deep trouble: its stack smashed (e.g., if it encountered SIGSEGV
On GNU and Unix systems, you can also trying sending Emacs SIGUSR2,
which, if 'debug-on-event' has its default value, will cause Emacs to
attempt to break it out of its current loop and into the Lisp
-debugger. This feature is useful when a C-level debugger is not
-conveniently available.
+debugger. (See the node "Debugging" in the ELisp manual for the
+details about the Lisp debugger.) This feature is useful when a
+C-level debugger is not conveniently available.
** If certain operations in Emacs are slower than they used to be, here
is some advice for how to find out why.