Debugger
Architecture and implementation of our debugging component are based on the Eclipse Debug Project (EDP) as it provides the Eclipse Debugging Framework (cf. Fig. 1) as a basis for user defined integrated Eclipse debuggers. The Control API of CoreASM provides information about the current status of the interpreter [Farahbod, Gervasi et al. 2004].
Although CoreASM offers a plugin interface, we decided to implement our debugger as a direct extension of CoreASM for Eclipse. A direct implementation facilitates access to the interpreter, its control, and allows for seamlessly extending the user interface of CoreASM. Necessary adaptions of the CoreASM project mainly affect the plugin.xml file. The classes implementing the corresponding model for our CoreASM debugger are shown in Fig. 2.
We prepare the conceptual basis for the implementation of the debugger through the transfer of concepts of the debugging of imperative programs to concepts of debugging of ASM specifications. Therefore, we characterize the following debugging concepts in terms of ASM: a debugging step, a line breakpoint, a watchpoint, a method breakpoint, a watch expression, and modification of data.
We will outline these concepts by means of an example (see below).
The debugger currently adds the following functions to CoreASM:
- the control mode "stepping" for the interpreter
- capabilities to debug CoreASM programs (EDP)
- line breakpoints
- watchpoints
- rule breakpoints (cf. method breakpoints)
- watch expressions
- variables view
- expressions view
- breakpoint view
- extensions that go beyond EDP
- updates view
- agent filter for updates view
- compare view for states
- compare view filter: show only changes
As an example, we debug a slightly modified version of the CoreASM sample specification "Dining Philosophers". The specification introduces five philosophers sitting around a table. Between two neighboring philosophers lies one chopstick. If a philosopher becomes hungry, he takes both chopsticks if possible and starts eating. If he is not hungry any more, he puts both chopsticks back on the table. Since all philosophers compete for the same chopsticks, not all of them can eat at the same time.
A CoreASM specification can be debugged by adding and running an eclipse debug configuration for a certain specification, in our case "DiningPhilosophers.casm".
The debugger can be started either as usual or in stepping mode, by pressing the stepping mode button (see Fig. 3). Stepping means that the interpreter will automatically pause after each update step.
During debugging, the standard eclipse debug control (see Fig. 4) can be used to control the CoreASM execution, e.g. to trigger the next execution step.
The updates of the last execution step are presented within the update view (see Fig. 5). Each entry of this view gives information about the source file and line of the line which caused the update, the line contents, and the executing agent. Entries, which are highlighted by a green symbol, are currently hit by a breakpoint.
Figure 6 shows the filter menu of the update view. It can be used to select a specific agent so that all updates caused by different agents are hidden.
The variables view (see Fig. 7) can be used to examine the current state of the CoreASM execution. The number of executed steps and the last selected agents are shown at the top of this view. Also, the values of all backgrounds, universes, and functions for their given location are shown.
Entries that have been changed in the last step are highlighted to make inspection easier. Using the context menu, by right-clicking on an entry, the function at the given location can be added to the list of watched expressions or its value can be modified by the user.
The user can add expressions to be observed during execution to the expressions view. An expression can be either a function at a given location or a function name. In the first case, the value of the function at its location is show for the current step. If the expression is a function name, a container is displayed which shows the function and its value for all defined locations.
The main component of CoreASM is the editor (see Fig. 9). The editor has been extended so that it seamlessly supports adding, removing, enabling, and disabling breakpoints by interacting with its left sidebar.
Alternatively, breakpoints can be managed using the breakpoints view of Eclipse (see Fig. 10).
A breakpoint is a clearly defined point in a program, where the execution stops if this point is reached. We consider three kinds of breakpoints:
- A watchpoint (see Fig. 9, l. 43) interrupts the interpretation if the marked function at any given location has been changed during the current execution step.
- A method breakpoint (rule breakpoint; see Fig. 9, l. 45) is hit if any update is caused by any statement within the rules' body.
- A line breakpoint (see Fig. 9, l. 47) causes the interpreter to pause if a statement of the marked line triggers an update within the current update set.
Moreover, the line containing the last update in the current update set is marked by an indicator (blue arrow; see Fig. 9, l. 49).
By double-clicking on an entry of the update view, the corresponding file at the appropriate line is opened inside the editor component.
[Farahbod, Gervasi et al. 2004] R. Farahbod, V. Gervasi, U. Glässer, and G. Ma. CoreASM Plug-In Architecture. In Rigorous Methods for Software Construction and Analysis, pages 147-169, 2009.