![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to ch15.r CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSD / ucb / lisp / lisplib / manual|
Return to ch15.r CVS log | Up to [CSRG BSD Unix] / 43BSD / ucb / lisp / lisplib / manual |
1.1 root 1:
2:
3:
4:
5:
6:
7:
8: CHAPTER 15
9:
10:
11: The FIXIT Debugger
12:
13:
14:
15:
16:
17:
18: 15.1. Introduction FIXIT is a debugging environment
19: for FRANZ LISP users doing program development. This
20: documentation and FIXIT were written by David S.
21: Touretzky of Carnegie-Mellon University for MACLisp,
22: and adapted to FRANZ LISP by Mitch Marcus of Bell
23: Labs. One of FIXIT's goals is to get the program run-
24: ning again as quickly as possible. The user is
25: assisted in making changes to his functions "on the
26: fly", i.e. in the midst of execution, and then compu-
27: tation is resumed.
28:
29: To enter the debugger type (_d_e_b_u_g). The debugger
30: goes into its own read-eval-print loop. Like the
31: top-level, the debugger understands certain special
32: commands. One of these is help, which prints a list
33: of the available commands. The basic idea is that you
34: are somewhere in a stack of calls to eval. The com-
35: mand "bka" is probably the most appropriate for look-
36: ing at the stack. There are commands to move up and
37: down. If you want to know the value of "x" as of some
38: place in the stack, move to that place and type "x"
39: (or (cdr x) or anything else that you might want to
40: evaluate). All evaluation is done as of the current
41: stack position. You can fix the problem by changing
42: the values of variables, editing functions or expres-
43: sions in the stack etc. Then you can continue from
44: the current stack position (or anywhere else) with the
45: "redo" command. Or you can simply return the right
46: answer with the "return" command.
47:
48: When it is not immediately obvious why an error
49: has occurred or how the program got itself into its
50: current state, FIXIT comes to the rescue by providing
51: a powerful debugging loop in which the user can:
52:
53: - examine the stack
54:
55: - evaluate expressions in context
56:
57: - enter stepping mode
58:
59: - restart the computation at any point
60: 9
61:
62: 9The FIXIT Debugger 15-1
63:
64:
65:
66:
67:
68:
69:
70: The FIXIT Debugger 15-2
71:
72:
73: The result is that program errors can be located and
74: fixed extremely rapidly, and with a minimum of frus-
75: tration.
76:
77: The debugger can only work effectively when extra
78: information is kept about forms in evaluation by the
79: lisp system. Evaluating (*_r_s_e_t _t) tells the lisp sys-
80: tem to maintain this information. If you are debugging
81: compiled code you should also be sure that the com-
82: piled code to compiled code linkage tables are
83: unlinked, i.e do (_s_s_t_a_t_u_s _t_r_a_n_s_l_i_n_k _n_i_l).
84:
85:
86: (debug [ s_msg ])
87:
88: NOTE: Within a program, you may enter a debug loop
89: directly by putting in a call to _d_e_b_u_g where you
90: would normally put a call to _b_r_e_a_k. Also, within
91: a break loop you may enter FIXIT by typing _d_e_b_u_g.
92: If an argument is given to DEBUG, it is treated
93: as a message to be printed before the debug loop
94: is entered. Thus you can put (_d_e_b_u_g |_j_u_s_t _b_e_f_o_r_e
95: _l_o_o_p|) into a program to indicate what part of
96: the program is being debugged.
97:
98:
99:
100:
101:
102:
103:
104:
105:
106:
107:
108:
109:
110:
111:
112:
113:
114:
115:
116:
117:
118:
119:
120:
121:
122:
123:
124:
125: 9
126:
127: 9 Printed: July 21, 1983
128:
129:
130:
131:
132:
133:
134:
135: The FIXIT Debugger 15-3
136:
137:
138:
139: ____________________________________________________
140:
141: _F_I_X_I_T _C_o_m_m_a_n_d _S_u_m_m_a_r_y
142:
143: TOP go to top of stack (latest expression)
144: BOT go to bottom of stack (first expression)
145: P show current expression (with ellipsis)
146: PP show current expression in full
147: WHERE give current stack position
148: HELP types the abbreviated command summary found
149: in /usr/lisp/doc/fixit.help. H and ? work too.
150: U go up one stack frame
151: U n go up n stack frames
152: U f go up to the next occurrence of function f
153: U n f go up n occurrences of function f
154: UP go up to the next user-written function
155: UP n go up n user-written functions
156: ...the DN and DNFN commands are similar, but go down
157: ...instead of up.
158: OK resume processing; continue after an error or debug loop
159: REDO restart the computation with the current stack frame.
160: The OK command is equivalent to TOP followed by REDO.
161: REDO f restart the computation with the last call to function f.
162: (The stack is searched downward from the current position.)
163: STEP restart the computation at the current stack frame,
164: but first turn on stepping mode. (Assumes Rich stepper is loaded.)
165: RETURN e return from the current position in the computation
166: with the value of expression e.
167: BK.. print a backtrace. There are many backtrace commands,
168: formed by adding suffixes to the BK command. "BK" gives
169: a backtrace showing only user-written functions, and uses
170: ellipsis. The BK command may be suffixed by one or more
171: of the following modifiers:
172: ..F.. show function names instead of expressions
173: ..A.. show all functions/expressions, not just user-written ones
174: ..V.. show variable bindings as well as functions/expressions
175: ..E.. show everything in the expression, i.e. don't use ellipsis
176: ..C.. go no further than the current position on the stack
177: Some of the more useful combinations are BKFV, BKFA,
178: and BKFAV.
179: BK.. n show only n levels of the stack (starting at the top).
180: (BK n counts only user functions; BKA n counts all functions.)
181: BK.. f show stack down to first call of function f
182: BK.. n f show stack down to nth call of function f
183: ____________________________________________________
184:
185:
186:
187:
188:
189:
190: 9
191:
192: 9 Printed: July 21, 1983
193:
194:
195:
196:
197:
198:
199:
200: The FIXIT Debugger 15-4
201:
202:
203: 15.2. Interaction with _t_r_a_c_e FIXIT knows about the
204: standard Franz trace package, and tries to make trac-
205: ing invisible while in the debug loop. However,
206: because of the way _t_r_a_c_e works, it may sometimes be
207: the case that the functions on the stack are really
208: un_i_n_t_e_r_ned atoms that have the same name as a traced
209: function. (This only happens when a function is
210: traced WHEREIN another one.) FIXIT will call atten-
211: tion to _t_r_a_c_e'_s hackery by printing an appropriate tag
212: next to these stack entries.
213:
214:
215:
216:
217: 15.3. Interaction with _s_t_e_p The _s_t_e_p function may be
218: invoked from within FIXIT via the STEP command. FIXIT
219: initially turns off stepping when the debug loop is
220: entered. If you step through a function and get an
221: error, FIXIT will still be invoked normally. At any
222: time during stepping, you may explicitly enter FIXIT
223: via the "D" (debug) command.
224:
225:
226:
227:
228: 15.4. Multiple error levels FIXIT will evaluate arbi-
229: trary LISP expressions in its debug loop. The evalua-
230: tion is not done within an _e_r_r_s_e_t, so, if an error
231: occurs, another invocation of the debugger can be
232: made. When there are multiple errors on the stack,
233: FIXIT displays a barrier symbol between each level
234: that looks something like <------------UDF-->. The
235: UDF in this case stands for UnDefined Function. Thus,
236: the upper level debug loop was invoked by an undefined
237: function error that occurred while in the lower loop.
238:
239:
240:
241:
242:
243:
244:
245:
246:
247:
248:
249:
250:
251:
252:
253:
254:
255: 9
256:
257: 9 Printed: July 21, 1983
258:
259:
260:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.