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/2
{
8652/0093}
{
AI95-00207-01}
{
AI95-00434-01}
An
inspection point is a point in the object
code corresponding to the occurrence of a pragma Inspection_Point in
the compilation unit.
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.
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}
{
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. 5.b/1
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 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/2
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
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/2
This paragraph
was deleted.Implementation defined:
Implementation-defined aspects of pragma
Inspection_Point.
8.b/2
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.
9/2
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 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.
Wording Changes from Ada 95
11.b/2
{
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).
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
