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
code validation.
Discussion: Inspection points are a high
level equivalent of break points used by debuggers.
Syntax
The form of a
pragma
Inspection_Point is as follows:
pragma Inspection_Point[(
object_name
{,
object_name})];
Legality Rules
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.
Static Semantics
{
8652/0093}
{
AI95-00207-01}
{
AI95-00434-01}
{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 declaration of 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.
{
8652/0093}
{
AI95-00207-01}
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.
Discussion: {
8652/0093}
{
AI95-00207-01}
If the short form of the pragma is used, then all visible objects are
inspectable. This implies that global objects from other compilation
units 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
Execution of a pragma Inspection_Point has no effect.
Discussion: {
AI95-00114-01}
Although an inspection point has no (semantic) effect, the removal or
adding of a new point could change the machine code generated by the
compiler.
Implementation Requirements
Reaching an inspection point is an external interaction
with respect to the values of the inspectable objects at that point (see
1.1.3).
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
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.
This paragraph
was deleted.
Documentation Requirement: For each inspection
point, a mapping between each inspectable object and the machine resources
where the object's value can be obtained shall be provided.
7 {
AI95-00209-01}
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
read of 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.
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'.
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.
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.
Wording Changes from Ada 95
{
8652/0093}
{
AI95-00207-01}
Corrigendum: Corrected the definition of the Inspection_Point
pragma to apply to only variables visible at the point of the pragma.
Otherwise, the compiler would have to assume that some other code somewhere
could have a pragma Inspection_Point, preventing many optimizations (such
as unused object elimination).
Sponsored by Ada-Europe