![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to ch15.n CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDTahoe / ucb / lisp / doc|
Return to ch15.n CVS log | Up to [CSRG BSD Unix] / 43BSDTahoe / ucb / lisp / doc |
1.1 root 1: .\" Copyright (c) 1980 Regents of the University of California.
2: .\" All rights reserved. The Berkeley software License Agreement
3: .\" specifies the terms and conditions for redistribution.
4: .\"
5: .\" @(#)ch15.n 6.2 (Berkeley) 5/14/86
6: .\"
7: ." $Header: /na/franz/doc/RCS/ch15.n,v 1.1 83/01/31 07:08:47 jkf Exp $
8: .Lc The\ FIXIT\ Debugger 15
9: .sh 2 Introduction \n(ch 1
10: FIXIT is a debugging environment for
11: .Fr
12: users doing program development. This documentation and FIXIT
13: were written by David S. Touretzky
14: of Carnegie-Mellon University for MACLisp, and adapted to
15: .Fr
16: by Mitch Marcus of Bell Labs. One of
17: FIXIT's goals is to get the program running again as quickly
18: as possible. The user is assisted in making changes to his
19: functions "on the fly", i.e. in the midst of execution, and
20: then computation is resumed.
21: .pp
22: To enter the debugger type \fI(debug)\fP.
23: The debugger goes into its own
24: read-eval-print loop. Like the top-level, the debugger understands
25: certain special commands. One of these is help, which prints a list of
26: the available commands. The basic idea is that you are somewhere in a
27: stack of calls to eval. The command "bka" is probably the most appropriate
28: for looking at the stack. There are commands to move up and down. If
29: you want to know the value of "x" as of some place in the stack, move to
30: that place and type "x" (or (cdr x) or anything else that you might want
31: to evaluate). All evaluation is done as of the current stack position.
32: You can fix the problem by changing the values of variables, editing
33: functions or expressions in the stack etc. Then you can continue from
34: the current stack position (or anywhere else) with the "redo" command.
35: Or you can simply return the right answer with the "return" command.
36: .pp
37: When it is not immediately obvious why an error has occurred
38: or how the program got itself into its current state, FIXIT
39: comes to the rescue by providing a powerful debugging loop
40: in which the user can:
41:
42: - examine the stack
43:
44: - evaluate expressions in context
45:
46: - enter stepping mode
47:
48: - restart the computation at any point
49:
50: The result is that program errors can be located and fixed
51: extremely rapidly, and with a minimum of frustration.
52: .pp
53: The debugger can only work effectively when extra information is kept
54: about forms in evaluation by the lisp system.
55: Evaluating \fI(*rset\ t)\fP tells the lisp system to maintain this
56: information.
57: If you are debugging compiled code you should also be sure that the
58: compiled code to compiled code linkage tables are unlinked, i.e
59: do \fI(sstatus\ translink\ nil)\fP.
60:
61: .Lf debug "[ s_msg ]"
62: .No
63: Within a program, you may enter a debug loop directly by
64: putting in a call to
65: .i debug
66: where you would normally put
67: a call to
68: .i break.
69: Also, within a break loop you may enter
70: FIXIT by typing
71: .i debug.
72: If an argument is given to DEBUG,
73: it is treated as a message to be printed before the debug loop
74: is entered. Thus you can put \fI(debug |just before loop|)\fP into
75: a program to indicate what part of the program is being debugged.
76:
77: .Eb
78: \fIFIXIT Command Summary\fP
79:
80: TOP go to top of stack (latest expression)
81: BOT go to bottom of stack (first expression)
82: P show current expression (with ellipsis)
83: PP show current expression in full
84: WHERE give current stack position
85: HELP types the abbreviated command summary found
86: in /usr/lisp/doc/fixit.help. H and ? work too.
87: U go up one stack frame
88: U n go up n stack frames
89: U f go up to the next occurrence of function f
90: U n f go up n occurrences of function f
91: UP go up to the next user-written function
92: UP n go up n user-written functions
93: ...the DN and DNFN commands are similar, but go down
94: ...instead of up.
95: OK resume processing; continue after an error or debug loop
96: REDO restart the computation with the current stack frame.
97: The OK command is equivalent to TOP followed by REDO.
98: REDO f restart the computation with the last call to function f.
99: (The stack is searched downward from the current position.)
100: STEP restart the computation at the current stack frame,
101: but first turn on stepping mode. (Assumes Rich stepper is loaded.)
102: RETURN e return from the current position in the computation
103: with the value of expression e.
104: BK.. print a backtrace. There are many backtrace commands,
105: formed by adding suffixes to the BK command. "BK" gives
106: a backtrace showing only user-written functions, and uses
107: ellipsis. The BK command may be suffixed by one or more
108: of the following modifiers:
109: ..F.. show function names instead of expressions
110: ..A.. show all functions/expressions, not just user-written ones
111: ..V.. show variable bindings as well as functions/expressions
112: ..E.. show everything in the expression, i.e. don't use ellipsis
113: ..C.. go no further than the current position on the stack
114: Some of the more useful combinations are BKFV, BKFA,
115: and BKFAV.
116: BK.. n show only n levels of the stack (starting at the top).
117: (BK n counts only user functions; BKA n counts all functions.)
118: BK.. f show stack down to first call of function f
119: BK.. n f show stack down to nth call of function f
120: .Ee
121: .sh 2 Interaction\ with\ \fItrace\fP
122: FIXIT knows about the standard Franz
123: trace package, and tries to make
124: tracing invisible while in the debug loop. However, because
125: of the way
126: .i trace
127: works, it may sometimes be the case that the
128: functions on the stack are really un\fIintern\fPed atoms that have
129: the same name as a traced function. (This only happens when
130: a function is traced WHEREIN another one.) FIXIT will call
131: attention to
132: .i trace's
133: hackery by printing an appropriate tag
134: next to these stack entries.
135:
136: .sh 2 Interaction\ with\ \fIstep\fP
137: The
138: .i step
139: function may be invoked
140: from within FIXIT via the STEP command. FIXIT initially turns off
141: stepping when the debug loop is entered. If you step through a function
142: and get an error, FIXIT will still be invoked normally. At
143: any time during stepping, you may explicitly enter FIXIT
144: via the "D" (debug) command.
145:
146: .sh 2 Multiple\ error\ levels
147: FIXIT will evaluate arbitrary LISP
148: expressions in its debug loop. The evaluation is not done within an
149: .i errset,
150: so, if an error occurs, another invocation of the debugger
151: can be made. When there are multiple errors on the stack,
152: FIXIT displays a barrier symbol between each level that
153: looks something like <------------UDF-->. The UDF in
154: this case stands for UnDefined Function. Thus, the upper
155: level debug loop was invoked by an undefined function error
156: that occurred while in the lower loop.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.