From 83c54ddf38dd70e2f8673b4928ee6c5f4030bdbf Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Fri, 22 Feb 2013 11:22:21 +0200 Subject: [PATCH] Improve instructions in etc/DEBUG, per bug #13775. --- etc/DEBUG | 33 ++++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/etc/DEBUG b/etc/DEBUG index 6cd0abeeaa5..709e8987d03 100644 --- a/etc/DEBUG +++ b/etc/DEBUG @@ -8,17 +8,28 @@ See the end of the file for license conditions. 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 the executable was made. That directory has a .gdbinit file -that defines various "user-defined" commands for debugging Emacs. -(These commands are described below under "Examining Lisp object -values" and "Debugging Emacs Redisplay problems".) - -** 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. +where the executable was made (the 'src' directory in the Emacs source +tree). That directory has a .gdbinit file that defines various +"user-defined" commands for debugging Emacs. (These commands are +described below under "Examining Lisp object values" and "Debugging +Emacs Redisplay problems".) + +Some GDB versions by default do not automatically load .gdbinit files +in the directory where you invoke GDB. With those versions of GDB, +you will see a warning when GDB starts, like this: + + warning: File ".../src/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". + +There are several ways to overcome that difficulty, they are all +described in the node "Auto-loading safe path" in the GDB user manual. + +** When you are trying to analyze failed assertions or backtraces, it +will be essential to compile Emacs either completely without +optimizations (set CFLAGS to "-O0 -g3") or at least (when using GCC) +with the -fno-crossjumping option in CFLAGS. 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 -- 2.11.4.GIT