| OCR Text |
Show 67 procedure calls can change arbitrarily large parts of the state. Machine instructions are common to all compiled languages, which makes events language independent. Disadvantages of using instruction level events are the large number of events and machine dependence. A large number of events, however, can be significantly reduced by an event filter. Since Dynascope provides introspection of a hypothetical processor, it can be easily ported to other computer platforms. The structure of an event in the execution stream is shown in Figure 4.3. evtime is zero at the start of the execution. It is incremented for each executed hypothetical instruction, evpc is the program counter, the address of the last executed instruction, evinst contains the last executed instruction, evaddr is the address of result and evres is the value of result, evold is the old value at the address of the result. Since instructions in the hypothetical processor have the property that they change at most one word in the address space of executor, one word in the event is enough to describe the result of an instruction. The filter reports its status in evcond. Two different approaches to filters have been implemented, an interpretative and a compiled approach. An interpretative filter consists of predefined tables, capable of evaluating multiple Boolean expressions on event values. The director loads these tables to determine a specific filtering operation. In a compiled approach, struct event { /* unsigned int evtime; unsigned int evpc; unsigned int evinst; unsigned int evaddr; unsigned int evres; unsigned int evold; unsigned int evcond; an execution stream event */ /* instruction counter */ /* program counter */ /* instruction */ /* result address */ /* result value */ /* old result value */ /* filter result */ Figure 4.3. Event Data Structure |
