summaryrefslogtreecommitdiff
path: root/nt/INSTALL
diff options
context:
space:
mode:
authorEli Zaretskii <eliz@gnu.org>2005-12-09 19:17:40 +0000
committerEli Zaretskii <eliz@gnu.org>2005-12-09 19:17:40 +0000
commit3a817827e0f8e1006da5247e1f3dbc258281f77d (patch)
tree56f3ad67e48be29858614cf8ec77f14dd295ce0e /nt/INSTALL
parentc95dddbee52712aaffb18c41dd914662f5cda8cd (diff)
downloademacs-3a817827e0f8e1006da5247e1f3dbc258281f77d.tar.gz
Add explanation of how to debug with GDB starting from the Emacs Abort dialog.
Diffstat (limited to 'nt/INSTALL')
-rw-r--r--nt/INSTALL37
1 files changed, 25 insertions, 12 deletions
diff --git a/nt/INSTALL b/nt/INSTALL
index 2fb673d47d2..d756585ce20 100644
--- a/nt/INSTALL
+++ b/nt/INSTALL
@@ -243,7 +243,19 @@
You should be able to debug Emacs using the debugger that is
appropriate for the compiler you used, namely DevStudio or Windbg if
- compiled with MSVC, or gdb if compiled with gcc.
+ compiled with MSVC, or GDB if compiled with GCC.
+
+ When Emacs aborts due to a fatal internal error, Emacs on Windows
+ pops up an Emacs Abort Dialog asking you whether you want to debug
+ Emacs or terminate it. If Emacs was built with MSVC, click YES
+ twice, and Windbg or the DevStudio debugger will start up
+ automatically. If Emacs was built with GCC, first start GDB and
+ attach it to the Emacs process with the "gdb -p EMACS-PID" command,
+ where EMACS-PID is the Emacs process ID (which you can see in the
+ Windows Task Manager), type the "continue" command inside GDB, and
+ only then click YES on the abort dialog. This will pass control to
+ the debugger, and you will be able to debug the cause of the fatal
+ error.
Emacs functions implemented in C use a naming convention that reflects
their names in lisp. The names of the C routines are the lisp names
@@ -254,17 +266,18 @@
easily set breakpoints or examine familiar lisp variables by name.
Since Emacs data is often in the form of a lisp object, and the
- Lisp_Object type is difficult to examine manually in the MSVC
- debugger, Emacs provides a helper routine called debug_print that
- prints out a readable representation of a Lisp_Object. (If you are
- using gdb, there is a .gdbinit file in the src directory which
- provides definitions that are useful for examining lisp objects. The
- following tips are mainly of interest when using MSVC.) The output
- from debug_print is sent to stderr, and to the debugger via the
- OutputDebugString routine. The output sent to stderr should be
- displayed in the console window that was opened when the emacs.exe
- executable was started. The output sent to the debugger should be
- displayed in its "Debug" output window.
+ Lisp_Object type is difficult to examine manually in a debugger,
+ Emacs provides a helper routine called debug_print that prints out a
+ readable representation of a Lisp_Object. If you are using GDB,
+ there is a .gdbinit file in the src directory which provides
+ definitions that are useful for examining lisp objects. Therefore,
+ the following tips are mainly of interest when using MSVC.
+
+ The output from debug_print is sent to stderr, and to the debugger
+ via the OutputDebugString routine. The output sent to stderr should
+ be displayed in the console window that was opened when the
+ emacs.exe executable was started. The output sent to the debugger
+ should be displayed in its "Debug" output window.
When you are in the process of debugging Emacs and you would like to
examine the contents of a Lisp_Object variable, popup the QuickWatch