Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!culdev1!drw
From: drw@culdev1.UUCP (Dale Worley)
Newsgroups: comp.emacs
Subject: using the internal Lisp debugger
Message-ID: <1759@culdev1.UUCP>
Date: Wed, 18-Nov-87 10:27:36 EST
Article-I.D.: culdev1.1759
Posted: Wed Nov 18 10:27:36 1987
Date-Received: Sat, 21-Nov-87 04:48:31 EST
Organization: Cullinet Software, Westwood, MA, USA
Lines: 42

conor@goose.UUCP (Conor Rafferty) writes:
| If I set a debug-on-entry point, jump into the subroutine, and type
| a few d's, I end up with the following "stack trace" which is
| gibberish to me. Is this the best I can expect?
| 
| Entering:
| * debug(exit "Entering debugger...")
| * message("Entering debugger...")
| * byte-code("\316\317!\210\303\320 ^K^K\321\322!\303^^^F^]^\^Z^Y^X\323\216\212\324\213))\210^N^F\211^V

A few points:

You can't debug anything if it is compiled into byte code.  You can
get around this if you find-file the source file for the function you
are interested in, and re-execute the defun that defines the function
(use eval-defun).

The "c" command means "continue on".  The only thing that will stop
execution (other than explicitly set breaks) is returning from stack
frames marked with a "*" in the Backtrace buffer.  This is best used
for "stepping over" the execution of a function.

The "d" command means "break on entry to next function".  This should
only be used if you have stopped execution at exit from a function.

If you have code that looks like:

	(function arg arg)
	(function2 arg arg)

Then the sequence of events is:

1. starting with being stopped at entry to function, type c
2. stops at exit from function, type d
3. stops at entry to function2, type c
4. stops at exit from function2.

Dale
-- 
Dale Worley    Cullinet Software      ARPA: culdev1!drw@eddie.mit.edu
UUCP: ...!seismo!harvard!mit-eddie!culdev1!drw
If you get fed twice a day, how bad can life be?