From 74d401dab72600e0a1fec42caf940d345a893552 Mon Sep 17 00:00:00 2001 From: Jason Self Date: Wed, 21 Jun 2017 11:06:04 -0700 Subject: [PATCH] Adding section 5. --- md/debugging.md | 190 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 190 insertions(+) diff --git a/md/debugging.md b/md/debugging.md index 7837184..7c45710 100644 --- a/md/debugging.md +++ b/md/debugging.md @@ -1086,6 +1086,196 @@ other functions were considered useful. The above seem to form a basic set in this system. At least they are useful and no one has yet suggested another type of breakpoint that would also prove useful. +V Final Thoughts about MEND +=========================== + +V.1 Monitoring of Values +------------------------ + +A feature that was originally considered to be important, and is +present in ESP[^4][^5], is the constant monitoring of values. This +feature has not been too happily received in MEND, but that may be due +more to the current implementation than to an inherent lack of +utility. + +Ideally one should not have to see the object being monitored or its +value if one does not want to. The debugging system should be capable +of performing certain actions upon, for example, a change in value. +This would be analogous to conditional breakpoints except that the +test would be performed after each step of execution of the +application program rather than at certain arbitrary times. + +One problem with the above scheme is the difficulty of testing for a +change in value (the basic test). For example, the value of an object +being monitored may be some sort of structure. During execution the +application program may not explicitly change the value of the object +but may change an element of the structure that the object evaluates +to. Assuming MEND had saved a pointer to the structure, if it now +evaluated the object being monitored, it would again find that +structure and assume that the value had not changed. However since an +element of the structure had changed, the programmer would probably +want to be notified. + +The only solution to the above dilemma is to at each step save a +complete representation to all levels of the value of the object in +some form that cannot be affected by the application program. This can +be done by, at each step, unparsing the value to be saved for future +tests into its printed (string) representation. Then the comparison of +current and previous values will simply be a string comparison, not +subject to sharing by the values. Unfortunately this may create +incredible amounts of "garbage." In fact, a circular list (quite +legal) will produce a string of infinite length! + +The solution finally chosen was to print the values of the objects +being monitored at each step and to let the user visually compare +versions. The values are &-printed as usual but may be examined in +full at will. + +When tested it became immediately obvious that the constant reprinting +wasted time and was distracting. A feature was added to cause printing +to occur only at controllable intervals, but that produced other +problems. Primarily the user might not see a change that had occurred +at one step until some later step when valuable information had +already been lost. One would also not have the opportunity to take +immediate action. + +What needs to be done at this point is to reduce the emphasis on such +pathological cases as described above. Printing should only occur at +well defined moments (i.e., when requested or when some recognizable +condition occurs). Only gross and easily testable changes in value +should be watched for (i.e., the value is a new object, entirely). +Conditional monitoring should be installed analogous to the conditions +of breakpoints. With all of this testing, a variety of indications +should be available as with breakpoints. + +V.2 Control Stack Display +------------------------- + +MEND's display of the application program's control stack has proven +to be by itself a highly useful debugging aid. This display can be and +often is used without any of MEND's other features to debug a faulty +program. It should also be emphasized that a valid use of this display +is to monitor a working program in order to understand its operation. +In this case, where the user of MEND is completely unfamiliar with the +operation of the application program, MEND's step-by-step display of +program execution is even more useful than in the normal debugging +situation. + +One of the unique features of MEND's "trace" of the application +program is that MEND shows both the code being executed and the +results of that execution. Since Muddle is an applicative language, +most of the results consist of values returned by evaluated objects. +By reflecting the returned values back into the original code, MEND +shows intermediate results in an intuitive manner for the user. + +Other programming languages could also benefit from this sort of +display. Too often a trace routine provided for debugging in a +language shows only results of execution, such as value assignments, +without showing the corresponding program steps, or it shows program +steps but leaves it to the programmer to insert instructions to show +intermediate results. What the programmer really needs to see is a +well-integrated display of both program instructions and results, such +as MEND provides. + +Muddle is an exceptional language in that the MEND display was +implemented fairly cleanly with just a package of Muddle functions and +without changes to the interpreter itself. With suitable language +enhancements, however, a similar display could be provided for LISP or +any other LISP-like language. Although major compiler modifications +would be required, a stack-oriented display might also be suitable for +a block structured language like ALGOL. + +Especially in a block structured language, where instructions might be +treated in groups rather than individually, but also in applicative +languages, it would be useful to be shown variable bindings as they +occur. Muddle does not provide any information about the occurrence of +bindings, so the programmer is not informed of such occurrences by +MEND. However when major modifications are made in a language to +provide a display similar to MEND's, it would probably be a mistake +not to include a provision for notifying the programmer of variable +bindings and unbindings as they occur. + +V.3 Simulation Vs. Multiprocessing +---------------------------------- + +Besides its control stack display, MEND's other major feature, and its +major difference from debugging systems like EEP or the first version +of MUMBLE, is its use of multiprocessing rather than simulation to +follow application program execution. (Even debugging aids that use +multiprocessing often do not work the way MEND does. While MEND is a +program written in the same language and running concurrently in the +same interpreter as the application program, some debuggers , such a +DDT, are machine language programs running near the application +program, and others are simply complied into the language itself.) +This feature is perhaps the key to MEND's success as a debugger. The +choice to avoid simulation certainly reduced the size and complexity +of MEND by two or three times and similarly affected run time. What +remains to be discussed are the tradeoffs involved in the choice. The +advantages just mentioned heavily favor the multiprocessing solution +but there are other considerations. + +If MEND had been implemented using simulation, it would for the +evaluation of each object determine which elements need evaluation; +evaluate those elements by recursively calling MEND's own evaluation +simulator; determine whether some function should be applied; +determine the effects of the required functional application, if any; +and cause those effects while displaying some representation of them +for the programmer. In short, MEND would duplicate the actions of +Muddle while maintaining and updating its own information about those +actions. Therefore MEND would at all times know exactly what the +application program was doing and could never miss some important +effects of execution or be fooled by an unusual program. In the +previous section it was stated that it is desirable to show the +occurrence of variable bindings to the programmer. This feature would +be easy to implement in a debugging system that simulated execution of +the application program. + +But what about a debugging system using multiprocessing? A +multiprocessing debugger, such as MEND, allow s the application +program to execute more-or-less freely in its own process while +monitoring it from another process. Since MEND id not in direct +control of the application program, it must rely for its information +on whatever data it is given by the multiprocessing mechanism built +into Muddle and on inferences based on examination of the application +program's environment, its knowledge of the general behavior of Muddle +programs, and some specific knowledge of special cases. The occurrence +of variable bindings is not decipherable from the information that +MEND can gather. Fortunately, as has been previously shown, MEND does +have the information essential to the creation of its display and the +display is a sufficient debugging tool. + +Monitoring execution of the application program from another process +provides sufficient information for a useful debugging system while +simulation of the application program provides enough information for +a more comprehensive system. Therefore if speed and size of the +debugger were not important factors, then, although not a necessary +choice, simulation would be the favored choice for a debugging system +except for one other factor. + +The simulator needs much more knowledge of specific details of the +behavior of program functions than does the monitor. In fact the +simulator must know exactly the effects of each function that might be +used in the application program. Uncompiled user-defined functions are +no problem. They consist merely of one or more applications of other +functions to given arguments. Complied user-defined functions cannot +be dealt with at all without actually creating a simulator for machine +language programs, a project comparable in magnitude to the design and +implementation of all of the other parts of the simulator combined! +The remaining functions are Muddle's built-in primitives. They are +well defined but frequently change (usually upward compatibly). +Furthermore new primitives are constantly being added. A simulator for +Muddle programs would therefore quickly become outdated. + +Given the problems of a simulator and the relatively few drawbacks of +a monitor, it is clear now why MEND was implemented as the latter. The +same arguments apply to debugging systems for other languages. +Whenever the appropriate multiprocessing features exist, with +sufficient information available about execution in another process, a +debugging system based upon simulation of the application program +should be rejected in favor of a monitor-type system. MEND has proven +to be an effective debugging aid and should serve as a good example of +the latter type of system. + [^1]: G.A. Mann, "A Survey of Debug Systems", Honeywell Computer Journal 1973, volume 7, number 3, pages 182-198 -- 2.31.1