(font-lock-keywords): Add defvar.

[gnu-emacs] / etc / DEBUG

diff --git a/etc/DEBUG b/etc/DEBUG
index 6419b3dfd81bfa535b5d8e1ae3c38185de89ac42..27f563a740515ab7e2ee5458ccc8d16a470bf5a5 100644 (file)
--- a/etc/DEBUG
+++ b/etc/DEBUG
@@ -1,5 +1,6 @@
 Debugging GNU Emacs
-Copyright (c) 1985, 2000, 2001 Free Software Foundation, Inc.
+Copyright (C) 1985, 2000, 2001, 2002, 2003, 2004,
+   2005 Free Software Foundation, Inc.
 
    Permission is granted to anyone to make or distribute verbatim copies
    of this document as received, in any medium, provided that the
@@ -17,8 +18,15 @@ should read the Windows-specific section near the end of this
 document.]
 
 ** When you debug Emacs with GDB, you should start it in the directory
-where you built Emacs.  That directory has a .gdbinit file that defines
-various "user-defined" commands for debugging Emacs.
+where the executable was made.  That directory has a .gdbinit file
+that defines various "user-defined" commands for debugging Emacs.
+
+** When you are trying to analyze failed assertions, it will be
+essential to compile Emacs either completely without optimizations or
+at least (when using GCC) with the -fno-crossjumping option.  Failure
+to do so may make the compiler recycle the same abort call for all
+assertions in a given function, rendering the stack backtrace useless
+for identifying the specific failed assertion.
 
 ** It is a good idea to run Emacs under GDB (or some other suitable
 debugger) *all the time*.  Then, when Emacs crashes, you will be able
@@ -62,6 +70,11 @@ use the set command until the inferior process has been started.
 Put a breakpoint early in `main', or suspend the Emacs,
 to get an opportunity to do the set command.
 
+When Emacs is running in a terminal, it is useful to use a separate terminal
+for the debug session.  This can be done by starting Emacs as usual, then
+attaching to it from gdb with the `attach' command which is explained in the
+node "Attach" of the GDB manual.
+
 ** Examining Lisp object values.
 
 When you have a live process to debug, and it has not encountered a
@@ -107,36 +120,32 @@ objects which you can examine in turn with the x... commands.
 Even with a live process, these x...  commands are useful for
 examining the fields in a buffer, window, process, frame or marker.
 Here's an example using concepts explained in the node "Value History"
-of the GDB manual to print the variable frame from this line in
-xmenu.c:
-
-                 buf.frame_or_window = frame;
-
-First, use these commands:
+of the GDB manual to print values associated with the variable
+called frame.  First, use these commands:
 
     cd src
     gdb emacs
-    b xmenu.c:1296
+    b set_frame_buffer_list
     r -q
 
-Then type C-x 5 2 to create a new frame, and it hits the breakpoint:
+Then Emacs hits the breakpoint:
 
     (gdb) p frame
-    $1 = 1077872640
+    $1 = 139854428
     (gdb) xtype
     Lisp_Vectorlike
     PVEC_FRAME
     (gdb) xframe
-    $2 = (struct frame *) 0x3f0800
+    $2 = (struct frame *) 0x8560258
     (gdb) p *$
     $3 = {
-      size = 536871989,
-      next = 0x366240,
-      name = 809661752,
+      size = 1073742931,
+      next = 0x85dfe58,
+      name = 140615219,
       [...]
     }
     (gdb) p $3->name
-    $4 = 809661752
+    $4 = 140615219
 
 Now we can use `pr' to print the name of the frame:
 
@@ -568,6 +577,13 @@ these data structures on the respective headers to remove the `:N'
 bitfield definitions (which will cause each such field to use a full
 int).
 
+** How to recover buffer contents from an Emacs core dump file
+
+The file etc/emacs-buffer.gdb defines a set of GDB commands for
+recovering the contents of Emacs buffers from a core dump file.  You
+might also find those commands useful for displaying the list of
+buffers in human-readable format from within the debugger.
+
 ** Some suggestions for debugging on MS Windows:
 
    (written by Marc Fleischeuers, Geoff Voelker and Andrew Innes)