From 5a625daa780f7e36da60b0e4a743d9b87d53a9d2 Mon Sep 17 00:00:00 2001 From: Jason Self Date: Fri, 16 Jun 2017 19:14:47 -0700 Subject: [PATCH] Finishing section 1, adding initial footnotes, restyling markdown text --- md/debugging.md | 514 ++++++++++++++++++++++++++++++++---------------- 1 file changed, 348 insertions(+), 166 deletions(-) diff --git a/md/debugging.md b/md/debugging.md index 9e19ab9..81c1c8e 100644 --- a/md/debugging.md +++ b/md/debugging.md @@ -1,200 +1,382 @@ -% A Dynamic Debugging System For Muddle -% Joel Mayer Berez -% January 1978 +--- +title: 'A Dynamic Debugging System For Muddle' +author: Joel Mayer Berez +date: January 1978 +abstract: Program debugging is a time consuming process. Conventional + debugging techniques and aids typically give the user a narrow view + of the program's operation, making debugging difficult. A debugging + system that would present a clear overall picture of a program's + behavior and would be both flexible and simple to operate would be a + valuable tool. Such a system was designed and implemented in and for + Muddle, a high-level applicative programming language. This report + discusses the design alternatives considered during the debugging + system's design and implementation phases, the reasons for the + resulting design choices, and the system attributes. A major + attribute of the system (MEND) is that it does not simulate the + program being debugged but instead monitors it from another + process. This attribute results in a robust and viable debugging + system, because MEND need not be modified in order to handle each + new extension to Muddle and/or each new user-defined primitive. +--- MIT Technical Memo 94 -Laboratory for Computer Science -Massachusetts Institute of Technology -545 Technology Square -Cambridge, Massachusetts 02139 - -# Copyright - -This report was originally published in the United States in January -1978 without a copyright notice and without subsequent registration -with the U.S. Copyright Office within 5 years. Doing at least one of -those was a requirement of United States copyright law at that time -[^1]. This report is therefore in the public domain in the United -States for failure to comply with the required formalities. This means -you're free to download, modify and redistribute this report. People -outside of the United States must check the copyright laws of their -country before downloading or redistributing. - -[^1]: - -# Abstract - -Program debugging is a time consuming process. Conventional debugging -techniques and aids typically give the user a narrow view of the -program's operation, making debugging difficult. A debugging system -that would present a clear overall picture of a program's behavior and -would be both flexible and simple to operate would be a valuable tool. -Such a system was designed and implemented in for Muddle, a high-level -applicative programming language. This report discusses: the design -alternatives considered during the debugging system's design and -implementation phases, the reasons for the resulting design choices, -and the system attributes. A major attribute of the system (MEND) is -that it does not simulate the program being debugged but instead -monitors it from another process. This attribute results in a robust -and viable debugging system, because MEND not be modified in order to -handle each new extension to Muddle and/or each new user-defined +Laboratory for Computer Science +Massachusetts Institute of Technology +545 Technology Square Cambridge, Massachusetts 02139 + +Copyright +========= + +This research was supported by the Advanced Research Projects Agency +of the Department of Defense and was monitored by the Office of Naval +Research under Contract No. N00014-75-C-0661. + +This report was originally published in the United States in January +1978 without a copyright notice and without subsequent registration +with the U.S. Copyright Office within 5 years. Doing at least one of +those was a requirement of United States copyright law at that time. +This report is therefore in the public domain in the United States for +failure to comply with the required formalities. This means you're +free to download, modify and redistribute this report. People outside +of the United States must check the copyright laws of their country +before downloading or redistributing. + +Abstract +======== + +Program debugging is a time consuming process. Conventional debugging +techniques and aids typically give the user a narrow view of the +program's operation, making debugging difficult. A debugging system +that would present a clear overall picture of a program's behavior and +would be both flexible and simple to operate would be a valuable tool. +Such a system was designed and implemented in for Muddle, a high-level +applicative programming language. This report discusses: the design +alternatives considered during the debugging system's design and +implementation phases, the reasons for the resulting design choices, +and the system attributes. A major attribute of the system (MEND) is +that it does not simulate the program being debugged but instead +monitors it from another process. This attribute results in a robust +and viable debugging system, because MEND not be modified in order to +handle each new extension to Muddle and/or each new user-defined primitive. -This report reproduces a thesis Of the same title submitted to the -Department of Electrical Engineering, Massachusetts Institute of -Technology, in partial fulfillment of the requirements for the Degree +This report reproduces a thesis of the same title submitted to the +Department of Electrical Engineering, Massachusetts Institute of +Technology, in partial fulfillment of the requirements for the Degree of Bachelor of Science. -# Acknowledgements +Acknowledgements +================ -I wish to thank Al Vezza, for supervising this work and guiding me -along the road to winnage; Stu Galley, for the original idea; Bruce -Daniels and Gerald Farrell, for laying some of the ground work I have -built upon; Brian Berkowitz and Chris Reeve, for patiently repairing -my ailing Muddles; Marc Blank and Tak To, for support work and for -providing me with company during all-night console sessions; and all -of the other ITS and DynaMod hackers who have built a system well +I wish to thank Al Vezza, for supervising this work and guiding me +along the road to winnage; Stu Galley, for the original idea; Bruce +Daniels and Gerald Farrell, for laying some of the ground work I have +built upon; Brian Berkowitz and Chris Reeve, for patiently repairing +my ailing Muddles; Marc Blank and Tak To, for support work and for +providing me with company during all-night console sessions; and all +of the other ITS and DynaMod hackers who have built a system well worth using. -This research was supported by the Advanced Research Projects Agency -of the Department of Defense and was monitored by the Office of Naval +This research was supported by the Advanced Research Projects Agency +of the Department of Defense and was monitored by the Office of Naval Research under Contract No. N00014-75-C-0661. -# Introduction +Introduction +============ -## Background +Background +---------- -A time-consuming and frustrating aspect of computer programming is the -debugging of faulty programs. Current debugging techniques involve -tracing through the present operation of the program and mentally -comparing its action with one's concept of what should be happening. -With few exceptions, an understanding of where the program fails to -conform to "correct" operation must be made before the cause of the -failure can be determined and corrective action taken. This is where +A time-consuming and frustrating aspect of computer programming is the +debugging of faulty programs. Current debugging techniques involve +tracing through the present operation of the program and mentally +comparing its action with one's concept of what should be happening. +With few exceptions, an understanding of where the program fails to +conform to "correct" operation must be made before the cause of the +failure can be determined and corrective action taken. This is where much of the difficulty occurs. -In conventional debugging, it is rare for the programmer to have -available any more than the most basic aids. One usually has to -extrapolate from a bare minimum of information (such as machine -generated error messages) or one may be buried under a large excess of -information, most irrelevant (such as a core dump). Even with the more -advanced aids, the programmer typically gets but a small window in the -operation of the program through which, sooner or later, she or he -will locate the problem. A well-localized fault will be relatively -easy to spot compared to a global problem that the programmer may only +In conventional debugging, it is rare for the programmer to have +available any more than the most basic aids. One usually has to +extrapolate from a bare minimum of information (such as machine +generated error messages) or one may be buried under a large excess of +information, most irrelevant (such as a core dump). Even with the more +advanced aids, the programmer typically gets but a small window in the +operation of the program through which, sooner or later, she or he +will locate the problem. A well-localized fault will be relatively +easy to spot compared to a global problem that the programmer may only catch glimpses of through the debugging window. -In a compiler language, the programmer's best hope is to insert -statements to print intermediate results or to try to separate the -program into easier-to-handle modules. There are a few more advanced -aids available, but their use is limited. One problem is that the -program is, in effect, first translated into a lower-level language -(generally "machine" language) and then executed interpretively in -that language. The original symbols and syntax of the source program -are lost, or saved only with great difficulty, making analysis and +In a compiler language, the programmer's best hope is to insert +statements to print intermediate results or to try to separate the +program into easier-to-handle modules. There are a few more advanced +aids available[^1], but their use is limited. One problem is that the +program is, in effect, first translated into a lower-level language +(generally "machine" language) and then executed interpretively in +that language. The original symbols and syntax of the source program +are lost, or saved only with great difficulty, making analysis and manipulation of the executing program a very painful process. -If the programmer is using an interpretive language with facilities -for interaction, things are considerably easier. The common technique -is to stop execution at strategic points and examine the state of the -environment. Since this is done interactively, with the source program -still available in more or less its original form, the cause of the -problem can often be found in less time than it could otherwise. one -of the best example of this approach is the use of DDT (Dynamic -Debugging Tool/Technique). - -DDT basically works with machine-language programs. However, by freely -translating between numbers and symbols through the use of a table -generated by the assembler, DDT makes programs look to the programmer -like symbolic assembly-language programs. The user of DDT can operate -in free-run mode or in n-step (statement) mode, switching between them -at will. In either case one can set a breakpoint at any statement, -which will cause execution to stop just before the statement is -executed. Whenever stopped in DDT, the user can examine or change the -contents of any location. This can be done in several data modes -(e.g., unsigned octal, full ASCII, sixbit, etc.) including the use of -symbols to represent addresses. Arbitrary numeric expressions can also +If the programmer is using an interpretive language with facilities +for interaction, things are considerably easier. The common technique +is to stop execution at strategic points and examine the state of the +environment. Since this is done interactively, with the source program +still available in more or less its original form, the cause of the +problem can often be found in less time than it could otherwise. one +of the best example of this approach is the use of DDT (Dynamic +Debugging Tool/Technique)[^2][^3]. + +DDT basically works with machine-language programs. However, by freely +translating between numbers and symbols through the use of a table +generated by the assembler, DDT makes programs look to the programmer +like symbolic assembly-language programs. The user of DDT can operate +in free-run mode or in n-step (statement) mode, switching between them +at will. In either case one can set a breakpoint at any statement, +which will cause execution to stop just before the statement is +executed. Whenever stopped in DDT, the user can examine or change the +contents of any location. This can be done in several data modes +(e.g., unsigned octal, full ASCII, sixbit, etc.) including the use of +symbols to represent addresses. Arbitrary numeric expressions can also be evaluated without affecting the program. -One main advantage of DDT is that the debugging environment is very -similar to the language environment the programmer used to write the -program. One has to learn only the DDT commands rather than an -entirely new language. Another advantage is the user's ability for -viewing the results of the changes. In addition, one can quickly see +One main advantage of DDT is that the debugging environment is very +similar to the language environment the programmer used to write the +program. One has to learn only the DDT commands rather than an +entirely new language. Another advantage is the user's ability for +viewing the results of the changes. In addition, one can quickly see the results of the changes and act accordingly. -The main deficiency of DDT is that, although is names include the word -"dynamic", its operation is really static. The application program can -run freely, but when the programmer wants to see what is taking place, -the program must be stopped. Although the real interest may be about -changes on a gross scale, perhaps thousands of program statements, if -one does not know exactly where the program is misbehaving, one may be -required to suspend execution of it every few instructions to examine -variable in order to obtain a true picture of the program's behavior. -This the programmers see *not what is taking place*, but *what has -taken place*, and through small windows at that. This is inefficient, -and the programmer can become bogged down in detail that hinders the -discovery of the true problem. The situation can be improved with the -use of breakpoints that allow the program is execute freely until a -breakpoint is reached, at which point the program halts. DDT is a +The main deficiency of DDT is that, although is names include the word +"dynamic", its operation is really static. The application program can +run freely, but when the programmer wants to see what is taking place, +the program must be stopped. Although the real interest may be about +changes on a gross scale, perhaps thousands of program statements, if +one does not know exactly where the program is misbehaving, one may be +required to suspend execution of it every few instructions to examine +variable in order to obtain a true picture of the program's behavior. +This the programmers see *not what is taking place*, but *what has +taken place*, and through small windows at that. This is inefficient, +and the programmer can become bogged down in detail that hinders the +discovery of the true problem. The situation can be improved with the +use of breakpoints that allow the program is execute freely until a +breakpoint is reached, at which point the program halts. DDT is a powerful tool but still leaves much to be desired in a debugging tool. -ESP (Execution Simulator and Presenter) is one solution to the static -problem. It really is dynamic is that large amounts of data are -constantly being displayed for the programmer while the program is -being executed (actually, simulated). The information is presented in -graphic form to improve readability and reduce confusion. A user of -ESP may watch areas of the display where data of particular interest -are being presented. One also has many options including control over -the speed of execution, the type of quantity of data displayed, and -special (more flexible than just a breakpoint) conditions for halting -execution. In this way one can structure and control the picture -presented to more easily understand what the simulated program is +ESP[^4][^5] (Execution Simulator and Presenter) is one solution to the +static problem. It really is dynamic is that large amounts of data are +constantly being displayed for the programmer while the program is +being executed (actually, simulated). The information is presented in +graphic form to improve readability and reduce confusion. A user of +ESP may watch areas of the display where data of particular interest +are being presented. One also has many options including control over +the speed of execution, the type of quantity of data displayed, and +special (more flexible than just a breakpoint) conditions for halting +execution. In this way one can structure and control the picture +presented to more easily understand what the simulated program is doing. And that is one key step in the process of debugging. -Like DDT, ESP has deficiencies also. These are mainly in the area of -editing and DDT-like examination of a faulty program. DDT is a -sophisticated language that ESP does not attempt to entirely replace. -The flaw in ESP is that it is not compatible with DDT. Ideally both -should be simultaneously available to the programmer, who can use +Like DDT, ESP has deficiencies also. These are mainly in the area of +editing and DDT-like examination of a faulty program. DDT is a +sophisticated language that ESP does not attempt to entirely replace. +The flaw in ESP is that it is not compatible with DDT. Ideally both +should be simultaneously available to the programmer, who can use features of each as the need dictates. -DDT and ESP work with a low-level language whose operation can be -shown fairly simply. For example, ESP often shows flow of control by -just displaying the actual section of program being executed and -pointing to the current statement. It also draws lines to show where -branching has occurred and in some cases even indicates looping. The -display philosophy can be readily extended to higher level languages -that are line oriented, like BASIC, but it fails with applicative -ones, like LISP or Muddle. The latter type does not use a linear -control flow, but uses a complex depth-first tree structure. -Furthermore, quite complicated data structures can be built (or -themselves executed) that bear little relation to the appearance of +DDT and ESP work with a low-level language whose operation can be +shown fairly simply. For example, ESP often shows flow of control by +just displaying the actual section of program being executed and +pointing to the current statement[^6]. It also draws lines to show +where branching has occurred and in some cases even indicates looping. +The display philosophy can be readily extended to higher level +languages that are line oriented, like BASIC, but it fails with +applicative ones, like LISP or Muddle. The latter type does not use a +linear control flow, but uses a complex depth-first tree structure. +Furthermore, quite complicated data structures can be built (or +themselves executed) that bear little relation to the appearance of the program. -A good basic display for Muddle was used in MUMBLE (Gerald Farrell's -monitor and debugging aid). The code being executed is shown in stack -form. Each line shows a piece of code being evaluated. As each object -in the bottom line is evaluated, it is replaced by a single -downward-arrow symbol in this line and then printed on a new line. In -this way the evaluation can be followed from the top level down to the -current object being evaluated. Furthermore, after the bottom is -reached, the value returned by each line replaces its symbol in the -previous line. With this mechanism, the programmer can follow +A good basic display for Muddle was used in MUMBLE[^7] (Gerald +Farrell's monitor and debugging aid). The code being executed is shown +in stack form. Each line shows a piece of code being evaluated. As +each object in the bottom line is evaluated, it is replaced by a +single downward-arrow symbol in this line and then printed on a new +line. In this way the evaluation can be followed from the top level +down to the current object being evaluated. Furthermore, after the +bottom is reached, the value returned by each line replaces its symbol +in the previous line. With this mechanism, the programmer can follow execution in a natural and reasonably clear representation. -MUMBLE had some difficulties arising from the fact that it simulated -execution rather than just watching it and letting it proceed -naturally. This caused it to run slowly and to be complex yet fragile. -At the time MUMBLE was written, the Muddle compiler was not yet -perfected and the language itself lacked some of the multiprocessing -features that would have made simulation unnecessary. Later Farrell -replaced MUMBLE with a debugger utilizing new software related to -single-stepping a process, which eliminated the simulation but also -eliminated the feature reflecting results of an evaluation back into -the original code. Also, a mode was added that allowed the programmer -to attach conditions to parts of the program which would stop -execution when and if a condition was false. This is as far as MUMBLE -ever progressed, and it was not in use as of the time of the proposal -for the current work. \ No newline at end of file +MUMBLE had some difficulties arising from the fact that it simulated +execution rather than just watching it and letting it proceed +naturally. This caused it to run slowly and to be complex yet fragile. +At the time MUMBLE was written, the Muddle compiler was not yet +perfected and the language itself lacked some of the multiprocessing +features that would have made simulation unnecessary. Later Farrell +replaced MUMBLE with a debugger utilizing new software related to +single-stepping a process, which eliminated the simulation but also +eliminated the feature reflecting results of an evaluation back into +the original code. Also, a mode was added that allowed the programmer +to attach conditions to parts of the program which would stop +execution when and if a condition was false. This is as far as MUMBLE +ever progressed, and it was not in use as of the time of the proposal +for the current work. + +MEND +---- + +After the Muddle compiler became operational and many additional new +software features became available, it appeared that it would be +possible to design and implement a debugging system that would be +comprehensive, easy to use, and reasonably fast. It was therefore +proposed that a debugging system for Muddle called MEND (Muddle +Executor , aNalyzer, and Debugger) be designed and implemented. It has +the following characteristics. (A glossary of special terms, those in +all capital letters, used here and throughout the rest of this memo +may be found in Appendix B.) + +1. MEND possesses a display similar to that of MUMBLE, including the + replacement of arguments in a FORM by their values as they are + evaluated. +2. Execution is monitored from another process (as opposed to being + simulated as in ESP) using 1STEP and related features[^8]. +3. Execution speed is variable by the user including a static single + or multi-step mode where desired. +4. MEND allows execution to run freely below a certain depth of + evaluation or between certain points in the program and to run + controlled elsewhere. +5. Unconditional and conditional breakpoints are available that can + be attached to any object to halt execution before evaluation of + that object. +6. The system is capable of keeping track of programmer specified + conditions and of changing modes or giving some visible indication + when the conditions are met (or not met). +7. Information, such as the local value of programmer specified ATOMs + and the values of programer specified FORMs, is constantly + displayed beneath the main display. +8. Each line in the main display area is &-printed (abbreviated + printing, see glossary) and can be viewed in full at any time. +9. At any time, with execution stopped, the user can EVAL objects in + the ENVIRONMENT of the program. This means the user can examine + the state of the program or change it. + +Possible Additional Characteristics +----------------------------------- + +Certain other characteristics were seen as desirable for MEND but +possibly beyond the scope of this project. If time permitted these +features were to be included in the system: + +1. The IMLAC multi-screen capability would be used to allow the user + to rapidly switch between the debugger display and the program's + own output. Other system output could also be put on additional + pages. +2. The editor IMED (an editor for Muddle objects analogous to + IMEDIT[^9]) would be tied into the system to allow easy editing. + PRINTTYPE and READ-TABLEs would be used to allow breakpoints to be + easily set and removed in IMED as single symbols. Other control + codes and statements could also be inserted using this editor. +3. At the applications programmer's option and within certain limits, + execution could be reversed either so that something different + could be tried or for purposes of reexamining the process for + something that may have been missed the first time. This feature + could come in two possible forms, the UNDO package[^10] to + actually reverse execution or a simulation displaying information + previously stored by the system. + +Design and Implementation +------------------------- + +MEND was designed with the intent of providing the application +programmer with many options so that debugging could proceed in the +most suitable manner for each situation. In the normal running state, +MEND displays several kinds of information on the screen. Most +important is an area showing the execution of the application program +being debugged in stack form. The only other area that is always +present is a line or two of status information about the current +operation of MEND showing its current speed of execution (user +adjustable) and the state of each modifiable mode. + +It was intended that the output of the application program be saved by +MEND for later reference. The user of MEND could then elect to have +the most recent output constantly displayed in a window on the main +screen (see section on future work). If multi-screening were +available, the output could be kept on another virtual screen. That +screen could be displayed or made invisible at the user's option +without stopping MEND. + +Information such as programmer specified values of ATOMs, structured +objects, and, in general, the value of any Muddle expression may be +constantly displayed. MEND is also capable of displaying such +information on an exception basis according to some predescribed +condition. Such information is &-printed but is viewable in full when +desired. + +It is important for a debugging system like MEND to be compatible with +and to take advantage of available software in related areas. One such +area is editing. There were two Muddle editors in use when the +proposal for this work was made, EDIT[^11] and IMED. The main +difference between them is that IMED uses the local editing features +of the IMLAC while EDIT does not. EDIT, however, has the advantage of +being the only one that possesses breakpoint capabilities. Whichever +proved to be most compatible with MEND (possibly both) would be +slightly modified to allow the setting and removing of certain MEND +codes including, in the case of IMED, breakpoints. + +Muddle itself has many features that greatly aid the debugging +process. One of these is FRAMES. This function can be used to print +the stack of functional evaluations and applications when execution is +halted at any depth below the top level. At this point it is also +possible to get the values of objects in the current ENVIRONMENT and +to change them. One can even restart execution at a higher level after +making such changes. Because the Muddle debugging features are quite +powerful, MEND was designed to allow the user to stop execution (of +the application program) and to use these aids or any others built in +to Muddle with the MEND system itself transparent. Evaluation would +take place in the ENVIRONMENT of the application program. + +MEND now includes the main features of all the debuggers that have +been mentioned and enough other features that it should prove to be +quit useful for the analysis and debugging of Muddle programs. It +should also serve as a good example of the type of debugging system +that can be built around an applicative type language. + +[^1]: G.A. Mann, "A Survey of Debug Systems", Honeywell Computer + Journal 1973, volume 7, number 3, pages 182-198 + +[^2]: Digital Equipment Corporation, "DDT-10 Programmer's Reference + Manual", Assembly Language Handbook, DEC-10-NRZA-D + +[^3]: B. Bressler, DDT: A Debugging Aid, SYS.06.01, Programming + Technology Division Document, Laboratory for Computer Science, + M.I.T., November, 1971 + +[^4]: S.W. Galley, Debugging with ESP -- Execution Simulator and + Presenter, SYS.09.01, Programming Technology Division Document, + Laboratory for Computer Science, M.I.T., November, 1971 + +[^5]: S.W. Galley and R.P. Goldberg, "Software Debugging: The Virtual + Machine Approach", Proceedings of the Association for Computing + Machinery Annual Conference, November, 1974, volume 2, pages + 395-401 + +[^6]: M.H. Liu, DETAIL: A Graphical Debugging Tool, S.B. Thesis, + Department of Electrical Engineering, M.I.T., February, 1972 + +[^7]: G.J. Farrell, A System for Muddle Programming, M.S. Thesis, + Department of Electrical Engineering, M.I.T., August, 1973 + +[^8]: S.W. Galley and G. Pfister, Muddle Programming Language Primer + and Manual, Laboratory for Computer Science, M.I.T., May, 1977 + +[^9]: J. Haverty, IMEDIT Editor Program for Use with the Imlac + Terminals, SYS.08.01.02, Programming Technology Division Document, + Laboratory for Computer Science, M.I.T., August, 1972 + +[^10]: B. Berkowitz, UNDO, Undergraduate Research Report, Programming + Technology Division, Laboratory for Computer Science, M.I.T., + December, 1974 + +[^11]: N. Ryan, EDIT: The Muddle Editor, SYS.11.14, Programming + Technology Division Document, Laboratory for Computer Science, + M.I.T., August, 1974 -- 2.31.1