Lines Matching refs:program

22 interaction between the debugger and the target program and
60 of the program, especially when
61 the state is embedded in the program's data structures.
65 It is based on the notion that the state and resources of a program
76 hardware; it deals with the program state and resources
91 arbitrary process partitioning or program structure. 
98 limited form of automated program verification without requiring
124 A program is a dynamic entity; questions asked when the program is in
125 a static state are meaningful only after the program has been `caught' in
126 that state. The framework for manipulating the program is still as
131 target program.
136 a server that executes NeDtcl programs operating on the target program.
145 integrate the manipulation of a program's resources into the debugger
153 in the target program cause events to be queued for processing by the
164 program symbols, source code, registers and type information. This
176 It focuses on representing program state and addressing data rather than
179 from an Acid program.
245 All variables and functions in the program
250 Syntactically, Acid variables and target program
257 program contains the address of that symbol in the image
258 of the program.  Thus, the value of a program variable is
261 address of the corresponding program variable.
291 the program being debugged.
305 information in the program symbol table, so Acid cannot
380 is the address of the function of the same name in the program under test.
390 Registers are treated as normal program variables referenced
434 A program executing under Acid is monitored through the
457 Any time a control message causes the program to execute instructions 
469 the program running again.
484 contains a list of the machine-specific register names. Global symbols in the target program
532 each time the target program stops, giving the user a visual
533 trace of the execution path of the program. A more complete interface
757 A single binary of Acid may be used to debug a program running on any
761 file system from an i486-based PC and remotely debug a program executing
766 decode the file header of the program being debugged and
802 Alef program bugs are often deadlocks, synchronization failures,
811 allows the programmer to interpret the program state in terms of
812 Alef operations.  Consider the example of a multi-process program
814 the program indicates that it is waiting for an event in some
821 the runtime data structures and program state to report the cause
831 the program.
851 to events generated in specific threads of the program.
854 modification: when the text segment of a program is written (usually to
872 For each complex object in the program the compiler generates
878 Alef or C program variables of a type with the functions
950 in the program being debugged.
989 an executing program allows passive test and
990 verification of the target program.  For example,
997 monitor the execution of a program and detect these
1030 The program is then started and continues until it
1046 a breakpoint at the return address and restarts the program.
1049 returns, the breakpoint stops the program,
1063 When the program exits, the list of outstanding memory blocks contains
1094 in use when the program terminated.
1113 The program is not
1119 Any programmer may then check a program's use of the
1138 on the output generated by statements compiled into the program.
1140 logs the progress of the program as it executes basic blocks and writes the
1145 modifying the source, object or binary of the program. The following example
1193 After placing the breakpoints the program is set running.
1196 from memory and then restarts the program.
1236 The name space clash between Acid variables, keywords, program variables,