T. A. Cargill and B. N. Locanthi. Cheap hardware support for software debugging and profiling. In Proceedings of the Second International Conference on Architectural Support for Programming Languages and Operating Systems, volume 22 of SIGPLAN Notices, pages 82--83, October 1987.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....and the task stack. To avoid the massive overhead introduced by sampling the entire contents of these areas, we use checksums instead [14] Although these checksms are not truly unique, they strongly aid in differentiating between program states. Other solutions to this problem have been proposed [2][10] but these are not suitable in the VxWorks case due to lack of kernel instrumentation possibilities, large overheads or specialized hardware requirements. 3.2 ABB Robotics Instrumentation In contrast to the system level control flow instrumentation, which is handled on the VxWorks RTOS ....

Cargill T.A. and B.N. Locanthi. Cheap Hardware Support for Software Debugging and Profiling. Proceedings of the Second International Conference on Architectural Support for Programming Languages and Operating Systems. Pp 82-83, October 1987.

....synchronous messages delivered to the destination process and its backup [1] The Hypervisor system provides primary backup replication transparently to the operating system and user applications. A virtual machine layer, inserted beneath the operating system, uses the hardware instruction counter [9] to count the instructions executed between two hardware interrupts. This information is collected on the primary machine and periodically sent over the network to the backup machine, which reproduces the effects of the primary s hardware interrupts [8] Transparent Fault Tolerance (TFT) is ....

T. Cargill and B. Locanthi. Cheap hardware support for software debugging and profiling. In Proceedings of the 2nd Symposium on Architectural Support for Programming Languages and Operating Systems, pages 82--83, 1987.

....are taken, or to combine checkpointing with event logging. 2.6 Interactions with the Outside World A message passing system often interacts with the outside world to receive input data or show the outcome of a computation. If a failure occurs, the outside world cannot be relied on to roll back [42]. For example, a printer cannot roll back the effects of printing a character, and an automatic teller machine cannot recover the money that it dispensed to a customer. It is therefore necessary that the outside world perceive a consistent behavior of the system despite failures. Thus, before ....

....of the Twenty Seventh International Symposium on Fault Tolerant Computing (FTCS 27) pp.48 57, Jun. 1997. 41] R.B. Netzer and J. Xu. Necessary and sufficient conditions for consistent global snapshots. In IEEE Transactions on Parallel and Distributed Systems, 6(2) 165 169, Feb. 1995. [42] R. Pausch. Adding input and output to the transactional model. Ph.D. Thesis, Carnegie Mellon University, August 1988. 43] J.S. Plank. Efficient checkpointing on MIMD architectures. Ph.D. Thesis, Princeton University, 1993. 44] J.S. Plank, M. Beck, G. Kingsley and K. Li. Lipckpt: ....

T. Cargill and B. Locanthi. "Cheap hardware support for software debugging and profiling." In Proceedings of the 2 nd Symposium on Architectural Support for Programming Languages and Operating Systems, pp. 82---83, Oct. 1987.

....instructions. It is set to zero at the beginning of the process execution and incremented for each executed instruction. This counter determines internal logical time in the process history [11] The instruction counter can be provided as a hardware or a software addition to an existing system [4, 14] or as a special register in the processor. The instruction set emulated on the interpreter is assumed to be a load store model [8] In this model, load and store are the only instructions that access main memory. Another assumption is that instructions take at most two operands and they produce ....

T. A. Cargill and B. N. Locanthi. Cheap hardware support for software debugging and profiling. In Proc. of the 2nd International Conference on Architectural Support for Programming Languages and Operating Systems, pages 82--83. ACM, 1987.

....and process termination. The events are detected by triggering upon access or execution of addresses related the events. Tsai s system records precise timing information for each event, to allow debugging of real time programs. Another form of hardware debugging support is an instruction counter [25]. Cargill and Locanthi describe such a counter as being loaded with a value that is decremented upon the execution of each instruction. When the counter reaches zero, an interrupt is generated. Instruction counters provide a simple way to profile code by determining the number of instructions exe7 ....

T.A. Cargill and B.N. Locanthi. Cheap hardware support for software debugging and profiling. In Proceedings of the 2nd International Conference on Architectural Support for Programming Languages and Operating Systems [48].

....is implemented by inserting checks during compilation. Magpie does not support monitoring of heap objects. To this date, no performance information has been reported for Magpie or for VAX DEBUG. Several authors have speculated that efficient data breakpoints require special purpose hardware [4, 11, 15]. To quantify the differences among data breakpoint implementation strategies, Wahbe [19] compared facilities based on specialized processor support, virtual memory page protection, checking the destination address of machine instructions via an operating system trap, and checking the destination ....

T. Cargill and B. Locanthi. "Cheap Hardware Support for Software Debugging and Profiling,". In Proceedings of the Second International Conference on Architectural Support for Programming Languages and Operating Systems, pages 82--83, October 1987. Appeared as SIGPLAN Notices 22(10).

....elements in the history represent a counter for reverse execution as well. To execute n instructions in reverse, the n latest elements are retrieved from the history and applied to the process state. Instruction counter can be provided as a hardware or a software addition to an existing system [4, 19] or as a special register in the processor. 2.3 The History Data Structure The history must be able to restore the entire state of a process: a program counter, registers, and the main memory. Assuming that a machine instruction modifies the program counter and at least one more location, a ....

T. A. Cargill and B. N. Locanthi. Cheap hardware support for software debugging and profiling. In Proc. of the 2nd International Conference on Architectural Support for Programming Languages and Operating Systems, pages 82--83. ACM, 1987.

....It is set to zero at the beginning of the 18 process execution and incremented for each executed instruction. This counter determines internal logical time in the process history [94] The instruction counter can be provided as a hardware or a software addition to an existing system [29, 115] or as a special register in the processor. The instruction set emulated on the interpreter is assumed to be a load store model [67] In this model, load and store are the only instructions that access main memory. Another assumption is that instructions take at most two operands and they produce ....

T. A. Cargill and B. N. Locanthi. Cheap hardware support for software debugging and profiling. In Proc. of the 2nd International Conference on Architectural Support for Programming Languages and Operating Systems, pages 82--83. ACM, 1987.

....depends on the points within the execution at which the interrupts occur. Thus, if the program always starts from a given state and receives the same interrupts at the same execution points, it will produce the same output. We use instruction counters to enable this form of repeatable execution [8]. Using these counters, it is possible to log the number of instructions executed between consecutive interrupts during normal operation. If a failure occurs, the instruction counts in the log and the counters are used to reapply the signals at the same execution points. Thus, a rollback recovery ....

....and the system reconstructs the pre failure execution. We first describe instruction counters and then show how we emulated them in software on two different architectures. 2. 1 Instruction Counters An instruction counter is a register that is decremented upon the execution of each instruction [8]. The hardware generates an exception when the register content becomes zero. An instruction counter can be used in two modes. In one, the register is loaded with the number of instructions to be executed. After the CPU executes the specified number of instructions, an exception is generated and ....

[Article contains additional citation context not shown here]

T. Cargill and B. Locanthi. Cheap hardware support for software debugging and profiling. In Proceedings of the 2nd Symposium on Architectural Support for Programming Languages and Operating Systems, pages 82--83, Oct. 1987.

....hold. Execution proceeds until an event of interest occurs, at which time the content of the counter is sampled, and the number of instructions executed since the time the counter was set is computed. The use of instruction counters has been suggested for debugging shared memory parallel programs [36, 122, 148]. Instruction counters can be used in rollback recovery to track the number of instructions that occur between asynchronous interrupts. A replay system can use the instruction count to force the execution of the same number of instructions between asynchronous interrupts. An instruction counter ....

T. Cargill and B. Locanthi. Cheap hardware support for software debugging and profiling. Proceedings of the 2nd Symposium on Architectural Support for Programming Languages and Operating Systems, pages 82--83, October 1987.

....utility for debugging. Many replay debuggers have been proposed, especially in connection with parallel programming systems [Curtis82,LeBlanc87,McDowell89] and the idea of using a log to govern or assist re execution is well established. One important issue in such systems is how to measure time: [Cargill87] proposed a hardware instruction counter; Mellor Crummey89] use assembly code level instrumentation to implement a counter in software. A higher level software counter is easier to use with a compiler that performs significant rewriting or optimization. Another key issue is how to support ....

. T.A. Cargill and B.N. Locanthi, "Cheap hardware support for software debugging and profiling," Proc. SIGPLAN '87 Symposium on Compiler Construction, pp. 8283, June 1987.

....the instruction counter is loaded with the number of instructions that preceded the interrupt; then it will reach zero and trap at precisely that point, and the effects of the original interrupt handler can be simulated. Hardware instruction counters have been implemented experimentally [3] as well as in the HP Precision RISC architecture [7] They can also be simulated in software by counting the number of backward branches and combining this count with the value of the program counter [12] Instruction counters can also be used to make multithreaded uniprocessor applications ....

Cargill, T. A., and Locanthi, B. N. Cheap hardware support for software debugging and profiling. In Second International Conference on Architectural Support for Programming Languages and Operating Systems (October 1987), pp. 82--83.

....the debugger s internal bookkeeping needs. We use a machine independent software clock, but there are other ways to provide the essential features of a clock, namely predictability, monotonicity, and an alarm feature. One alternative approach is to count machine instructions, either in hardware (Cargill and Locanthi, 1987) or software (Mellor Crummey and LeBlanc, 1989) and cause an interrupt after a certain number of instructions have been executed. Another, suitable for heap based languages like SML NJ, is to use the allocation pointer as a sort of clock whose alarm is set by altering the heap limit (Wilson and ....

....single stepping to locate matching events (Feldman and Brown, 1988; Grishman, 1970) which is prohibitively slow. 13 Our implementation of speculative computation shows that, for monotone predicates, a binary search based on time travel can be much more efficient. Our approach was inspired by Cargill and Locanthi (1987); a similar idea was used in more limited fashion in IGOR (Feldman and Brown, 1988) Several existing systems use reverse execution primarily as a foundation for more sophisticated debugging aids. These include visualization (Teitelbaum and Reps, 1981) flowback analysis, the automated display ....

Cargill, T. A. and Locanthi, B. N. (1987). Cheap hardware support for software debugging and profiling. In Proc. Second International Conference on Architectural Support for Programming Languages and Operating Systems, pages 82--83.

No context found.

T. A. Cargill and B. N. Locanthi. Cheap hardware support for software debugging and profiling. In Proceedings of the Second International Conference on Architectural Support for Programming Languages and Operating Systems, volume 22 of SIGPLAN Notices, pages 82--83, October 1987.

No context found.

T.A. Cargill and B.N. Locanthi. Cheap Hardware Support for Software Debugging and Profiling. pages 82 -- 83, October 1987.

No context found.

T.A. Cargill and B.N. Locanthi. Cheap Hardware Support for Software Debugging and Profiling. pages 82 -- 83, October 1987.

No context found.

T. A. Cargill and B. N. Locanthi, `Cheap hardware support for software debugging and profiling', Proc. 2nd Int. Conf. on Architectural Support for Programming Languages and Operating Systems, 1987, pp. 82--83.

No context found.

T.A. Cargill, B.N. Locanthi, "Cheap hardware support for software debugging and profiling", ACM SIGPLAN Notices, Vol. 22, No. 10, pp. 82-83, 1992.

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