of event-grammar is introduced to describe allowed event patterns over .... destination :: ( variable I array-elt ). The event vocabulary must be rich enough to help us to describe the ..... Let [al, a2, ..., aN1 denoteasequence, bagor set containing ...
PARFORMAN - an Assertion Language for Specifying Behaviour when Debugging Parallel Applications Mikhail Auguston* and Peter Fritzson?
* Research Institute of Mathematics & Computer Science, The University of Latvia, Riga, Latvia -f Dept. of Computer and Information Science, Linkoping University, S-581 83 LinkUping, Sweden debugging) is to specify models of intended program behavior, and perform debugging by comparing these models with the actual behavior. PARFORMAN is intended to be used in this area in conjunction with some high-level programming language which we will refer to as the target language from now on. The assertion language is based on a semantic model of the met language where an execution is represented by a partially ordered set of events. This semantic model is defined by a contextfree event-grammar which describes allowed event patterns and is very close to the abstract syntax grammar of the target language. A number of language constructs in PARFORMAN are provided for writing assertions about events and event sequences.These include quantifiers and other aggregateoperations Over events. Sequence. bag and set constructors are also provided in addition to map and reduce operators, precedence relations, and operations of the target language to write assertions about target program variables. The general notion of event supported by PARFORMAN makes it possible to write assertionsnot only about variable values at program points but also about data and control flows in the target program. Assertions can also be used as conditions in rules which describe actions. For example, an error message to the user is a typical action from a debuser or consistency checker. certain general types of assertionscanbe written in a general way for certain classes of application programs and may be collected in standard libraries which can be designed and distributed as special software tools. These libraries can be used for dynamic analysis, e.g. to check the presence of typical bugs. Thus, PARFORMAN is a powerful and general language to describe computations Over program execution event history (H-space), and it may be considered as an example of a special programming paradigm. In this paper, a large subset of the Occam programming language [lll is used as a target language. Since observed results are hard to reproduce in parallel
Abstract PARFORMAN (PARallel FORMal ANnotation language) is a specifcation language for expressing intended behaviour or known types of error conditions when debugging or testing parallel programs. The high-level debugging approach which is supported by PARFORMAN is model-based.Models of intended or faulty behaviour can be succinctly specified in PARFORMAN. These models are then compared with the actual behaviour in terms of execution traces of events, in order to localize possible bugs. PARFORMAN is based on an axiomatic model of target program behavior. This model, called H-space {Historyspace), isformally defined through a set of general axioms about three basic relations between events. Events may be sequentially ordered, they may be parallel, or one of them might be included in another composite event. The notion of event-grammar is introduced to describe allowed event patterns over a certain application domain or language. Auxiliary composite events such as snapshots are introduced to be able to deJne the notion “occurred at the same time” at suitable levels of abstraction. In addition to debugging and testing, PARFORMAN can also be used to specify prof les and performance measurements.
1
Introduction
By using formal speciikations of intended program behavior, it is possible to develop powerful testing and debugging techniques. For example, algorithmic debugging is a general theory for semi-automatic debuggers which automatically localize bugs by Comparing the actual program behavior with the intended program behaviour. Infamation about the intended program behaviour is gradually acquired by questioning the user, who either answers yes/no questions about simple assertions or gives more general assertions. Algorithmic debuggers for the sequential case are described in 1123 and [SI. whereas a cancurrent algorithmic debugger is presented in [8]. A general methodological principle in parallel and distributed debugging (and also in the area of automated 150
1066-619Y92$3.000 1992 IEEE
and distributed debugging, tracing plays a prominent role (see e.g. 161). Post-mortem analysis of saved program execution traces using event data bases and possibly program replay are unnmon teEhniques. Thus, most methods for comparing intended and actual behavior are based on tracing events in execution histories. Similar to PARFORMAN.the Event Based Behavioral Abstraction @BA) method suggested in l3.41 characterizes the behavior of the whole program both in terms of primitive and composite events. Events can be defined by the user and do not necessarily have a relation to the semantics of the programming language for programs to be debugged, whereas PARFORMAN uses the notion of event-grammarsto define language-orientedprimitive and composite events. The event-grammar makes PARFORMAN more suitable for automatic source code inshumentation to detect complex composite events. Annotation languages is another approach to assertionbased debugging. The approaches currently in use are mostly based on boolean expressions attached to selected points of m e t program. The ANNA 191 annotation language for the ADA target language supports assertions on variable and type declarations. In the TSL [lo] annotation language for ADA the notion of event is introduced in order to describe the behavior of tasks. The only kind of event considered in TSL is Task entry call. Thus, it is not possible to d e h e and use composite events. A natural way to integrate debugging and testing leads to introduction of assertions in order to describe allowed patterns of system behavior. We believe that the contributions of PARFORMAN are in this area.
must satisfy the following axioms:
2
3
1. Commutativity/noncommutativity a I I b-b II a a
