Contents   Index   Search   Previous   Next

H.3.2 Pragma Inspection_Point

1
   An occurrence of a pragma Inspection_Point identifies a set of objects each of whose values is to be available at the point(s) during program execution corresponding to the position of the pragma in the compilation unit. The purpose of such a pragma is to facilitate code validation.
1.a
Discussion: Inspection points are a high level equivalent of break points used by debuggers.

Syntax

2
The form of a pragma Inspection_Point is as follows:
3
  pragma Inspection_Point[(object_name {, object_name})];

Legality Rules

4
   A pragma Inspection_Point is allowed wherever a declarative_item or statement is allowed. Each object_name shall statically denote the declaration of an object.
4.a
Discussion: The static denotation is required, since no dynamic evaluation of a name is involved in this pragma.

Static Semantics

5/1
     {8652/0093} {inspection point} An inspection point is a point in the object code corresponding to the occurrence of a pragma Inspection_Point in the compilation unit. {inspectable object} An object is inspectable at an inspection point if the corresponding pragma Inspection_Point either has an argument denoting that object, or has no arguments and the object is visible at the inspection point .
5.a
Ramification: If a pragma Inspection_Point is in an in-lined subprogram, there might be numerous inspection points in the object code corresponding to the single occurrence of the pragma in the source; similar considerations apply if such a pragma is in a generic, or in a loop that has been ``unrolled'' by an optimizer.
5.a.1/1
{8652/0093} The short form of the pragma is a convenient shorthand for listing all objects which could be explicitly made inspectable by the long form of the pragma; thus only visible objects are made inspectable by it. Objects that are not visible at the point of the pragma are not made inspectable by the short form pragma. This is necessary so that implementations need not keep information about (or prevent optimizations on) a unit simply because some other unit might contain a short form Inspection_Point pragma.
5.b/1
Discussion: {8652/0093} If the short form of the pragma is used, then all visible objects are inspectable. This implies that global objects from other compilation units objects out of scope at the point of the pragma are inspectable. A good interactive debugging system could provide information similar to a post-mortem dump at such inspection points. The annex does not require that any inspection facility is provided, merely that the information is available to understand the state of the machine at those points.

Dynamic Semantics

6
   Execution of a pragma Inspection_Point has no effect.
6.a
Discussion: Although an inspection point has no (semantic) effect, the removal or adding a new point could change the machine code generated by the compiler.

Implementation Requirements

7
   Reaching an inspection point is an external interaction with respect to the values of the inspectable objects at that point (see 1.1.3).
7.a
Ramification: The compiler is inhibited from moving an assignment to an inspectable variable past an inspection point for that variable. On the other hand, the evaluation of an expression that might raise an exception may be moved past an inspection point (see 11.6).

Documentation Requirements

8
   For each inspection point, the implementation shall identify a mapping between each inspectable object and the machine resources (such as memory locations or registers) from which the object's value can be obtained.
8.a
Implementation defined: Implementation-defined aspects of pragma Inspection_Point.
NOTES
9
7  The implementation is not allowed to perform ``dead store elimination'' on the last assignment to a variable prior to a point where the variable is inspectable. Thus an inspection point has the effect of an implicit reference to each of its inspectable objects.
10
8  Inspection points are useful in maintaining a correspondence between the state of the program in source code terms, and the machine state during the program's execution. Assertions about the values of program objects can be tested in machine terms at inspection points. Object code between inspection points can be processed by automated tools to verify programs mechanically.
10.a
Discussion: Although it is not a requirement of the annex, it would be useful if the state of the stack and heap could be interrogated. This would allow users to check that a program did not have a `storage leak'.
11
9  The identification of the mapping from source program objects to machine resources is allowed to be in the form of an annotated object listing, in human-readable or tool-processable form.
11.a
Discussion: In principle, it is easy to check an implementation for this pragma, since one merely needs to check the content of objects against those values known from the source listing. In practice, one needs a tool similar to an interactive debugger to perform the check.

Contents   Index   Search   Previous   Next   Legal