Contents Index Search Previous Next
H.3.2 Pragma Inspection_Point
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
points are a high level equivalent of break points used by debuggers.
The form of
a pragma Inspection_Point is as
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.
Discussion: The static
denotation is required, since no dynamic evaluation of a name is involved
in this pragma.
is a point in the object code corresponding to
the occurrence of a pragma Inspection_Point in the compilation unit.
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
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.
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
If the short form of the pragma is used, then all visible objects
are inspectable. This implies that global objects from other compilation
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
Execution of a pragma Inspection_Point has no
an inspection point has no (semantic) effect, the removal or adding a
new point could change the machine code generated by the compiler.
Reaching an inspection point is an external interaction
with respect to the values of the inspectable objects at that point (see
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).
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.
Implementation defined: Implementation-defined
aspects of pragma Inspection_Point.
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.
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.
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'.
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
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