1 % A Dynamic Debugging System For Muddle
7 Laboratory for Computer Science
8 Massachusetts Institute of Technology
10 Cambridge, Massachusetts 02139
14 This report was originally published in the United States in January
15 1978 without a copyright notice and without subsequent registration
16 with the U.S. Copyright Office within 5 years. Doing at least one of
17 those was a requirement of United States copyright law at that time
18 [^1]. This report is therefore in the public domain in the United
19 States for failure to comply with the required formalities. This means
20 you're free to download, modify and redistribute this report. People
21 outside of the United States must check the copyright laws of their
22 country before downloading or redistributing.
24 [^1]: <http://copyright.cornell.edu/resources/publicdomain.cfm>
28 Program debugging is a time consuming process. Conventional debugging
29 techniques and aids typically give the user a narrow view of the
30 program's operation, making debugging difficult. A debugging system
31 that would present a clear overall picture of a program's behavior and
32 would be both flexible and simple to operate would be a valuable tool.
33 Such a system was designed and implemented in for Muddle, a high-level
34 applicative programming language. This report discusses: the design
35 alternatives considered during the debugging system's design and
36 implementation phases, the reasons for the resulting design choices,
37 and the system attributes. A major attribute of the system (MEND) is
38 that it does not simulate the program being debugged but instead
39 monitors it from another process. This attribute results in a robust
40 and viable debugging system, because MEND not be modified in order to
41 handle each new extension to Muddle and/or each new user-defined
44 This report reproduces a thesis Of the same title submitted to the
45 Department of Electrical Engineering, Massachusetts Institute of
46 Technology, in partial fulfillment of the requirements for the Degree
47 of Bachelor of Science.
51 I wish to thank Al Vezza, for supervising this work and guiding me
52 along the road to winnage; Stu Galley, for the original idea; Bruce
53 Daniels and Gerald Farrell, for laying some of the ground work I have
54 built upon; Brian Berkowitz and Chris Reeve, for patiently repairing
55 my ailing Muddles; Marc Blank and Tak To, for support work and for
56 providing me with company during all-night console sessions; and all
57 of the other ITS and DynaMod hackers who have built a system well
60 This research was supported by the Advanced Research Projects Agency
61 of the Department of Defense and was monitored by the Office of Naval
62 Research under Contract No. N00014-75-C-0661.
68 A time-consuming and frustrating aspect of computer programming is the
69 debugging of faulty programs. Current debugging techniques involve
70 tracing through the present operation of the program and mentally
71 comparing its action with one's concept of what should be happening.
72 With few exceptions, an understanding of where the program fails to
73 conform to "correct" operation must be made before the cause of the
74 failure can be determined and corrective action taken. This is where
75 much of the difficulty occurs.
77 In conventional debugging, it is rare for the programmer to have
78 available any more than the most basic aids. One usually has to
79 extrapolate from a bare minimum of information (such as machine
80 generated error messages) or one may be buried under a large excess of
81 information, most irrelevant (such as a core dump). Even with the more
82 advanced aids, the programmer typically gets but a small window in the
83 operation of the program through which, sooner or later, she or he
84 will locate the problem. A well-localized fault will be relatively
85 easy to spot compared to a global problem that the programmer may only
86 catch glimpses of through the debugging window.
88 In a compiler language, the programmer's best hope is to insert
89 statements to print intermediate results or to try to separate the
90 program into easier-to-handle modules. There are a few more advanced
91 aids available, but their use is limited. One problem is that the
92 program is, in effect, first translated into a lower-level language
93 (generally "machine" language) and then executed interpretively in
94 that language. The original symbols and syntax of the source program
95 are lost, or saved only with great difficulty, making analysis and
96 manipulation of the executing program a very painful process.
98 If the programmer is using an interpretive language with facilities
99 for interaction, things are considerably easier. The common technique
100 is to stop execution at strategic points and examine the state of the
101 environment. Since this is done interactively, with the source program
102 still available in more or less its original form, the cause of the
103 problem can often be found in less time than it could otherwise. one
104 of the best example of this approach is the use of DDT (Dynamic
105 Debugging Tool/Technique).
107 DDT basically works with machine-language programs. However, by freely
108 translating between numbers and symbols through the use of a table
109 generated by the assembler, DDT makes programs look to the programmer
110 like symbolic assembly-language programs. The user of DDT can operate
111 in free-run mode or in n-step (statement) mode, switching between them
112 at will. In either case one can set a breakpoint at any statement,
113 which will cause execution to stop just before the statement is
114 executed. Whenever stopped in DDT, the user can examine or change the
115 contents of any location. This can be done in several data modes
116 (e.g., unsigned octal, full ASCII, sixbit, etc.) including the use of
117 symbols to represent addresses. Arbitrary numeric expressions can also
118 be evaluated without affecting the program.
120 One main advantage of DDT is that the debugging environment is very
121 similar to the language environment the programmer used to write the
122 program. One has to learn only the DDT commands rather than an
123 entirely new language. Another advantage is the user's ability for
124 viewing the results of the changes. In addition, one can quickly see
125 the results of the changes and act accordingly.
127 The main deficiency of DDT is that, although is names include the word
128 "dynamic", its operation is really static. The application program can
129 run freely, but when the programmer wants to see what is taking place,
130 the program must be stopped. Although the real interest may be about
131 changes on a gross scale, perhaps thousands of program statements, if
132 one does not know exactly where the program is misbehaving, one may be
133 required to suspend execution of it every few instructions to examine
134 variable in order to obtain a true picture of the program's behavior.
135 This the programmers see *not what is taking place*, but *what has
136 taken place*, and through small windows at that. This is inefficient,
137 and the programmer can become bogged down in detail that hinders the
138 discovery of the true problem. The situation can be improved with the
139 use of breakpoints that allow the program is execute freely until a
140 breakpoint is reached, at which point the program halts. DDT is a
141 powerful tool but still leaves much to be desired in a debugging tool.
143 ESP (Execution Simulator and Presenter) is one solution to the static
144 problem. It really is dynamic is that large amounts of data are
145 constantly being displayed for the programmer while the program is
146 being executed (actually, simulated). The information is presented in
147 graphic form to improve readability and reduce confusion. A user of
148 ESP may watch areas of the display where data of particular interest
149 are being presented. One also has many options including control over
150 the speed of execution, the type of quantity of data displayed, and
151 special (more flexible than just a breakpoint) conditions for halting
152 execution. In this way one can structure and control the picture
153 presented to more easily understand what the simulated program is
154 doing. And that is one key step in the process of debugging.
156 Like DDT, ESP has deficiencies also. These are mainly in the area of
157 editing and DDT-like examination of a faulty program. DDT is a
158 sophisticated language that ESP does not attempt to entirely replace.
159 The flaw in ESP is that it is not compatible with DDT. Ideally both
160 should be simultaneously available to the programmer, who can use
161 features of each as the need dictates.
163 DDT and ESP work with a low-level language whose operation can be
164 shown fairly simply. For example, ESP often shows flow of control by
165 just displaying the actual section of program being executed and
166 pointing to the current statement. It also draws lines to show where
167 branching has occurred and in some cases even indicates looping. The
168 display philosophy can be readily extended to higher level languages
169 that are line oriented, like BASIC, but it fails with applicative
170 ones, like LISP or Muddle. The latter type does not use a linear
171 control flow, but uses a complex depth-first tree structure.
172 Furthermore, quite complicated data structures can be built (or
173 themselves executed) that bear little relation to the appearance of
176 A good basic display for Muddle was used in MUMBLE (Gerald Farrell's
177 monitor and debugging aid). The code being executed is shown in stack
178 form. Each line shows a piece of code being evaluated. As each object
179 in the bottom line is evaluated, it is replaced by a single
180 downward-arrow symbol in this line and then printed on a new line. In
181 this way the evaluation can be followed from the top level down to the
182 current object being evaluated. Furthermore, after the bottom is
183 reached, the value returned by each line replaces its symbol in the
184 previous line. With this mechanism, the programmer can follow
185 execution in a natural and reasonably clear representation.
187 MUMBLE had some difficulties arising from the fact that it simulated
188 execution rather than just watching it and letting it proceed
189 naturally. This caused it to run slowly and to be complex yet fragile.
190 At the time MUMBLE was written, the Muddle compiler was not yet
191 perfected and the language itself lacked some of the multiprocessing
192 features that would have made simulation unnecessary. Later Farrell
193 replaced MUMBLE with a debugger utilizing new software related to
194 single-stepping a process, which eliminated the simulation but also
195 eliminated the feature reflecting results of an evaluation back into
196 the original code. Also, a mode was added that allowed the programmer
197 to attach conditions to parts of the program which would stop
198 execution when and if a condition was false. This is as far as MUMBLE
199 ever progressed, and it was not in use as of the time of the proposal
200 for the current work.