head 1.1;A access ; symbols ; locks ; strict; comment @# @; 1.1 date 85.03.31.18.35.39; author bbanerje; state Exp; branches ; next ; desc @@ 1.1 log @Initial revision @ text @Debugging GNU Emacs Copyright (c) 1985 Richard M. Stallman. Permission is granted to anyone to make or distribute verbatim copies of this document as received, in any medium, provided that the copyright notice and permission notice are preserved, and that the distributor grants the recipient permission for further redistribution as permitted by this notice. Permission is granted to distribute modified versions of this document, or of portions of it, under the above conditions, provided also that they carry prominent notices stating who last changed them. I have included in the distribution a version of dbx (for the Vax) which can debug GNU Emacs. The dbx that I found installed originally has several serious bugs that prevent it from loading GNU Emacs and cause GNU Emacs to malfunction. This debugger is the file tdbx in directory ../dbx. It has the same commands that dbx standardly has. The file .dbxinit in ../src defines some useful aliases; it also sets up signal handling in a way that permits GNU Emacs to work properly. If you are using INTERRUPT_INPUT in Emacs, the first input character you type after starting Emacs under tdbx will return control to tdbx, which will say that a "possible input" signal occurred. Then type ignore 23 and continue. The first character you typed to cause this signal will not be read by Emacs, but any more input will be read. If you wish to start Emacs again with another run command, you must (I believe) do `catch 23' first, then `ignore 23' after the first input character again. I have tried putting the `ignore 23' command in .dbxinit, but input does not work at all in Emacs if this is done. It appears to be necessary to type it after getting to tdbx once after starting the program. I cannot figure out from the dbx source why this is so. Some problems remain in this version of dbx. For example, it does not print union types at all, and most interesting data in GNU Emacs is of union type, Lisp_Object. The only thing you can do is examine the value in hex using &variable/X. The top two digits are the data type (with the mark bit in the sign bit during garbage collection) and the remaining six digits are the value or pointer. The `where' command (abbreviated `w') tends to get confused and print infinite garbage past the end of the real contents of the stack. Be prepared to stop it with Control-c. The `stop in' command tends to get into an infinite loop. If this happens, just type Control-c. You will find that the stop has been established properly. If you stop a looping dbx command with Control-c, it signals both dbx and the debugged Emacs. As a result, the next time you continue or step Emacs, it will stop immediately and say "interrupt". You must continue or step it again. I tried to fix this, by making the debugged process run in a different process group, but could not get it to work. `Fsignal' is a very useful place to stop in. All Lisp errors go through there. It is useful, when debugging, to have a guaranteed way to return to the debugger at any time. If you have INTERRUPT_INPUT defined in config.h, then Emacs is using raw mode and the only way you can do it is to store the code for some character into the variable stop_character: set keyboard.stop_character = 29 makes Control-] (decimal code 29) the stop character. Typing Control-] will cause immediate stop. You cannot 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. If you have FRONT_END_PROCESS or CBREAK_INPUT defined in config.h, then typing Control-g will cause a SIGINT, which will return control to dbx immediately unless you have done ignore 3 You will note that most of GNU Emacs is written to avoid declaring a local variable in an inner block, even in cases where this would be the cleanest thing to do. This is because dbx cannot access any of the variables in a function which has even one variable defined in an inner block. A few functions in GNU Emacs do have variables in inner blocks, only because I wrote them before realizing that dbx had this problem and never rewrote them to avoid it. dbx has many other deficiencies. If I find that I can really use it as part of GNU, I will fix them. If I will have to write another debugger, fixing dbx further is useless to me. @