Tolmach, A. and Appel, A, "Debugging Standard ML Without Reverse Engineering", 1990.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....target to locate a bug, and neither of them supports flexible data examination at arbitrary execution cycles. These problems have been recognized in prior research[5] 71] and can be characterized as low functionality and high complexity. Various possible improvements have been described[5][80], e.g. reversible execution and dynamic slicing. Both these methods allow execution information to be collected only after it is known to be useful to current hypothesis verification at a given breakpoint. These approaches have direct influenced described in this thesis. In order to collect prior ....

.... powerful, this approach has often been avoided because numerous execution state checkpoints can consume huge amounts of memory space and significantly degrade system performance[11] One of the few successful exceptions to this assessment is a debugger developed for the ML programming language[80]. As a functional language, ML[47] has only a few non functional effects (mutable store and I O operations) The functional part of ML execution can therefore be captured completely in a continuation[26] a feature supported directly by the language and by the SML NJ compiler[7] Continuation ....

[Article contains additional citation context not shown here]

A. P. Tolmach and A. W. Appel, "Debugging Standard ML Without Reverse Engineering", Proceedings of 1990 ACM Conference on Lisp and Functional Programming, ACM Press, 1990.

....C: Tracing Lazy Functional Computations. C. 6 Related work Some previous systems for tracing functional programs systems have been based on monitoring the series of events in a computation [KHC91] perhaps with the ability to examine events immediately preceding or following a suspected fault [TA90]. This approach is viable for a strict functional language with eager evaluation but breaks down for non strict languages with a lazy evaluation strategy. In a Haskell computation closures for function applications can lie dormant for many reductions. If no equation matches when a closure comes to ....

A.P. Tolmach and A.W. Appel. Debugging standard ML without reverse engineering. In Proceedings of the 1990 ACM Conference on LISP and Functional Programming, pages 1--12, June 1990. BIBLIOGRAPHY 201

....become easier to construct the necessary programming language definitions. 13 The other issue is that it still remains to see how our definition can be used as the basis of an implementation. Recent research has shown how source code transformations can be used effectively to implement debuggers [TA90, Spa94]. We are currently working on using this implementation technique to develop an implementation based on our style of formal definition. 5 Conclusions In this paper we compared three different approaches to defining a simple debugger for a functional programming language. From these definitions, ....

A. P. Tolmach and A. W. Appel. Debugging Standard ML without reverse engineering. In 1990 ACM Conference on Lisp and Functional Programming. Association for Computing Machinery, ACM Press, June 1990.

.... Methods have been proposed to help programmers at this stage by allowing the reverse execution of programs, but these methods require that every assignment encountered during the execution of the program be memorized, which makes them only applicable to functional programs with few side effects [21]. It would thus be desirable to have a framework allowing the static, formal and automatic debugging of programs. Even though this might seem impossible at first glance, since the general problem of finding all the bugs in a program is undecidable, we introduce in this paper an assertionbased ....

Andrew P. Tolmach and Andrew W. Appel: "Debugging Standard MLWithout Reverse Engineering", Proc. 1990 ACM Conf. on Lisp and Functional Programming, ACM Press (1990) 1--12

....on. Portability ensures that a director can be easily ported to a new computing platform, while heterogeneity ensures that the director can direct executors running on different computing platforms. Advanced directing tools are often implemented in environments that provide interpreted execution [13, 15, 19, 20, 21, 22, 28, 29]. Tools in these environments utilize the 2 underlying interpreter which is extended with the specialized support for debugging and performance monitoring. Such an interpreter does not exist for compiled programs, which are directly executed by hardware, so a different approach is required. ....

A. P. Tolmach and A. W. Appel. Debugging standard ML without reverse engineering. In Proc. ACM Lisp and Functional Programming Conference '90. ACM, 1990. 25

....shows how we have achieved modularization of our support: concurrency within a transaction is packaged in TRANS THREAD; concurrency among transactions, in RW LOCK; transaction undoability, in UNDO. Second, we guarantee the principle of isolation for transactions by making use of safe refs [9] (and correspondingly safe arrays) In the context of just threads, a normal SML ref is unsafe, while a ref protected by a mutex is a safe ref. In the context of transactions, a ref protected by only a mutex is an unsafe ref, while a ref protected by both a mutex and a read write lock is a safe ....

A.P. Tolmach and A.W. Appel. Debugging Standard ML without reverse engineering. In Proceedings of the ACM Lisp and Functional Programming Conference, pages 1--12, 1990.

....language, there is a wide range of choices for the granularity of steps. An execution step can be a construct from a high level language at one extreme or a machine instruction at the other extreme. Each step is described by an event. The use of events in monitoring process behavior is common [2, 6, 7, 13, 15, 16, 19, 23]. Usually events provide only that subset of process behavior which is important for a particular application. For example, Hanson [6] provides the following events: variable referencing, statement execution, program interruption, function call and return, and execution time errors. Events have ....

....application. For example, Hanson [6] provides the following events: variable referencing, statement execution, program interruption, function call and return, and execution time errors. Events have been implemented in interpretive environments [6, 16] or by augmenting source code to emit events [3, 23]. Although the content of events used to monitor programs in high level programming languages is often at a high level [3, 6, 10, 16, 23] high level events are not the most appropriate choice for introspective computer systems. In many cases, high level events are not able to describe the ....

[Article contains additional citation context not shown here]

A. P. Tolmach and A. W. Appel. Debugging standard ML without reverse engineering. In Proc. ACM Lisp and Functional Programming Conference '90. ACM, 1990.

....via the weak pointer, then the collector nullifies the pointer and reclaims the object s storage. SML NJ provides weak pointers as a language level mechanism to detect when objects become unreachable. Weak pointers are used A High performance Garbage Collector for Standard ML 11 by the debugger [TA90] to cache checkpoints, and are used in the SML NJ Library to implement a finalization mechanism. To implement weak pointers, the collector keeps a list of the encountered weak pointers; at the end of the collection it scans the list and nullifies those that point to dead objects. In a ....

Tolmach, A. P. and A. W. Appel. Debugging Standard ML without reverse engineering. In Conference record of the 1990 ACM Conference on Lisp and Functional Programming, June 1990, pp. 1--12.

....generated by arithmetic overflow. This, however, is a reminder of a comment by Hall and O Donnell [64] that error values tend to be oriented towards handling exceptional numeric conditions and are less useful in other circumstances. 4.3. 3 Instrumentation of the SML NJ compiler Tolmach and Appel [87] describe a system that uses automatic instrumentation of the user s code. They note that programmers will instrument their code to print out values, or trace the flow of control, when attempting to locate an error. The key idea is to insert such instrumentation automatically wherever an ....

....the error(s) occur, and perhaps suggest remedies. Which of the existing schemes provide a solution Kieburtz [54] Hall and O Donnell [64] and Kishon [55] all include in their conception, implemented in some form by the last two, a trace of the computation available to the user. Tolmach and Appel [87] get the compiler to instrument the user s code. This has an advantage that transformations to the code are reflected in transformations to the debugging information, so there is no problem in relating the two. The T flag in the Chalmer s LML compiler has a similar effect, and does allow ....

Andrew P. Tolmach and Andrew W. Appel. Debugging Standard ML Without Reverse Engineering. In ACM Conference on LISP and FunctionalProgramming, pages 1--12, Nice, France, 1990. ACM Press.

....for: process control; state access; breakpoint handling; tracing; and dynamic loading and linking. Some of the Dynascope primitives are shown in Figure 5. Dynascope interface is described in detail elsewhere [30] Although powerful debugging primitives usually require interpreted environments [16, 20, 21, 22, 27, 31, 32], Dynascope operates in traditional, compiled environments. It is compatible with existing compilers, linkers, and other development tools. Dynascope is implemented as two libraries, the client library and the directing server. To use Dynascope, the client library must be linked with the debugger ....

A. P. Tolmach and A. W. Appel. Debugging standard ML without reverse engineering. In Proc. ACM Lisp and Functional Programming Conference '90. ACM, 1990.

....a suitable version of the tracer. 6 Related work Some previous systems for tracing functional programs systems have been based on monitoring the series of events in a computation [KHC91] perhaps with the ability to examine events immediately preceding or following a suspected fault [TA90]. This approach is viable for a strict functional language with eager evaluation but breaks down for non strict languages with a lazy evaluation strategy. In a Haskell computation closures for function applications can lie dormant for many reductions. If no equation matches when a closure comes to ....

A. P. Tolmach and A. W. Appel. Debugging Standard ML without reverse engineering. In Proc. ACM conf. on Lisp and functional programming. ACM Press, 1990.

....enables many new techniques such as a generic undo operation, a real time checkpoint, and fast backtracking. 1 Introduction Reverse execution provides access to old states of an executing process. It is a well established concept in computer science used in program development and debugging [2, 6, 20, 21, 27, 28, 30], in programming environments and human computer interaction [1, 10, 16, 18, 29] in fault tolerant computing [5, 7, 14, 15] and in speculative computation [9, 13] In computer architecture, techniques of reverse execution are used to provide precise interrupts [12, 23] Implementations of reverse ....

A. P. Tolmach and A. W. Appel. Debugging standard ML without reverse engineering. In Proc. ACM Lisp and Functional Programming Conference '90. ACM, 1990.

....task. Examples of directors are debuggers and performance monitors. Any user program can act as an executor. Because the corresponding interpreters can be easily extended with support for debuggers and performance monitors, advanced directing tools are usually a domain of interpreted languages [14, 16, 20, 21, 22, 23, 27, 28]. But hardware which executes programs in compiled programs is fixed and a different approach is required. A platform to support directing for compiled programs depends on major components of computer systems: computer architectures, operating systems, networking, and existing programming tools. ....

A. P. Tolmach and A. W. Appel. Debugging standard ML without reverse engineering. In Proc. ACM Lisp and Functional Programming Conference '90. ACM, 1990.

....made them attractive, but a satisfactory way to incorporate garbage collection and a sophisticated run time environment in introspective systems was not found. Therefore, the decision was made to use C. Each step is described by an event. The use of events in monitoring process behavior is common [15, 64, 66, 111, 120, 121, 150, 168]. Usually events provide only that subset of process behavior which is important for a particular application. For example, Hanson [64] provides the following events: variable referencing, statement execution, program interruption, function call and return, and execution time errors. Events have ....

....For example, Hanson [64] provides the following events: variable referencing, statement execution, program interruption, function call and return, and execution time errors. Events have been implemented in interpretive environments [64, 121] or by augmenting source code to emit events [24, 168]. Although the content of events used to monitor programs in high level programming languages is often at a high level [24, 64, 89, 121, 168] high level events are not the most appropriate choice for introspective computer systems. In many cases, high level events are not able to describe the ....

[Article contains additional citation context not shown here]

A. P. Tolmach and A. W. Appel. Debugging standard ML without reverse engineering. In Proc. ACM Lisp and Functional Programming Conference '90. ACM, 1990.

....flag is set and the current thread is resumed, otherwise the current thread is placed in the ready queue and another thread is dispatched. 4 To simplify this presentation, we only concern ourselves with SIGALRM. 4. 3 Debugging Tolmach and Appel have built a replay debugger for SML NJ [TA90] . They use source to source transformations in the compiler to instrument the user s code. The debugger uses a software counter to keep track of the current time. The instrumentation code increments this counter and compares it against a target time at important points, called events, in the ....

Tolmach, A.P. and A.W. Appel. "Debugging standard ml without reverse engineering," Proceedings of the 1990 ACM Conference on Lisp and Functional Programming, June 1990, pp. 1-12.

....CML is the lack of debugging facilities. A short term solution is to provide a version of the CML primitives that allows monitoring of communication, thread scheduling, etc. A more ambitious scheme is to provide an interactive debugger. Andrew Tolmach, who is responsible for the SML NJ debugger [TA90] is working on a concurrent version for a safe version of ML threads [TA91] It is likely that his work can be adapted to CML; in fact, CML may be a better target than ML threads, since the shared state is more clearly defined. Chapter 12 discussed many of the issues relating to the ....

Tolmach, A. P. and A. W. Appel. Debugging Standard ML without reverse engineering. In Conference record of the 1990 ACM Conference on Lisp and Functional Programming, June 1990, pp. 1--12.

....In OOPSLA 88 Conference Proceedings, pp. 18 26, San Diego, CA, October, 1988. Published as SIGPLAN Notices 23(11) November, 1988. SW78] H. Schlaeppi and H. Warren. Design of the FDS Interactive Debugging System. IBM Research Report RC7214, IBM Yorktown Heights, July 1978. Tolmach and Appel [TA90] describe a debugger for ML where the compiler always performs optimizations, but where the program is automatically annotated with debugging statements before compilation. To debug an optimized program, the programmer has to manually recompile and reexecute the program. Like unoptimized programs, ....

Andrew P. Tolmach and Andrew W. Appel. Debugging Standard ML Without Reverse Engineering. In Proceedings of the 1990 ACM Conference on Lisp and Functional Programming, Nice, France, June 1990, pp. 1-12.

....for: process control; state access; breakpoint handling; tracing; and dynamic loading and linking. Some of the Dynascope primitives are shown in Figure 11. The Dynascope interface is described in detail elsewhere [31] Although powerful debugging primitives usually require interpreted environments [17, 23, 24, 29, 32, 33], Dynascope operates in traditional, compiled environments. It is compatible with existing compilers, linkers, and other development tools. Dynascope has no special provisions for optimized code. It always retrieves variable values from the program s address space in the main memory. If the right ....

A. P. Tolmach and A. W. Appel. Debugging standard ML without reverse engineering. In Proc. ACM Lisp and Functional Programming Conference '90. ACM, 1990.

....in real time, but usually they are not a standard part of computer equipment and are not integrated into programming environments. Therefore, general programming tools cannot rely on the availability of hardware monitors. Software approaches to monitoring include event generation and processing [1, 3, 6, 8, 12, 13, 14, 17, 18]. An executor, written in a high level language, produces events that are related to concepts in that high level language. Examples of such events include function calls or changes in variable values. Events are processed by event handlers included in the program itself [10] by a postprocessing ....

A. P. Tolmach and A. W. Appel. Debugging standard ML without reverse engineering. In Proc. ACM Lisp and Functional Programming Conference '90, Nice, June 1990. ACM.

....Debugging, Santa Cruz, CA, May 20 21, 1991. y Supported in part by NSF Grant CCR 9002786. derlying machine model (assuming the compiler functions correctly) We have used this fact to build an effective interactive debugger for sequential ML based on automatic source code instrumentation [25]. When code is compiled under debugger control, special hooks are inserted at frequent intervals (roughly once per basic block) Later, when the program runs, the debugger can use these hooks to gain control, answer user queries, and support breakpointing. All the added code is itself written in ....

A.P. Tolmach and A.W. Appel, "Debugging Standard ML without reverse engineering," Proc. 1990 ACM Conference on Lisp and Functional Programming, 1-12, June 1990.

No context found.

Tolmach, A. and Appel, A, "Debugging Standard ML Without Reverse Engineering", 1990.

No context found.

Andrew P. Tolmach and Andrew W. Appel. Debugging Standard ML without reverse engineering. In Proceedings of the 1990 ACM Conference on Lisp and Functional Programming, pages 1--12, New York, June 1990. ACM Press.

No context found.

A. P. Tolmach and A. W. Appel. Debugging standard ML without reverse engineering. In Proceedings of the 1990.

No context found.

AP Tolmach and AW Appel. Debugging Standard ML without reverse engineering. In Proc ACM Conference on Lisp and Functional Programming, Nice. ACM, June 1990.

No context found.

AP Tolmach and AW Appel. Debugging Standard ML without reverse engineering. In Proc ACM Conference on Lisp and Functional Programming, Nice. ACM, June 1990.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC