md/debugging.md

   1 % A Dynamic Debugging System For Muddle
   2 % Joel Mayer Berez
   3 % January 1978
   4
   5 MIT Technical Memo 94
   6
   7 Laboratory for Computer Science
   8 Massachusetts Institute of Technology
   9 545 Technology Square
  10 Cambridge, Massachusetts 02139
  11
  12 # Copyright
  13
  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.
  23
  24 [^1]: <http://copyright.cornell.edu/resources/publicdomain.cfm>
  25
  26 # Abstract
  27
  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
  42 primitive.
  43
  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.
  48
  49 # Acknowledgements
  50
  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
  58 worth using.
  59
  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.
  63
  64 # Introduction
  65
  66 ## Background
  67
  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.
  76
  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.
  87
  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.
  97
  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).
 106
 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.
 119
 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.
 126
 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.
 142
 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.
 155
 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.
 162
 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
 174 the program.
 175
 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.
 186
 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.