Designs for better debug info in GCC

Geert Bosch
Mon Dec 17 08:13:00 GMT 2007

On Dec 16, 2007, at 20:27, Joe Buck wrote:
> I have some sympathy for going in Alexandre's direction, in that it
> would be nice to have a mode that provided optimization as well as
> accurate debugging.  However, since preserving accurate debug  
> information
> has a cost, I think it would be better to turn -O1, not -O2, into the
> mode that Alexandre wants, where debug information is preserved.   
> Trying
> to rework all optimizations to keep perfect debug information is going
> to take forever and make the compiler worse.

Right, at the moment -O1 is far too much like -O2.
There is room for an optimization mode that is mostly local,
scales well far large programs and allows for high-quality debug
information. Fortunately, these goals seem all to match.

We could conceptually have inspection points between each source
statement and declaration, which would roughly correspond to a
use of all memory and all source variables, wether in memory or
in registers.
These inspections points would be considered potentially trapping.

This approach would still allow some scheduling. For example, loads
and arithmetic operations that are known not to trap could still
be done early. On the other hand, when breaking at any statement,
all variables can be printed.

Also, since no user-visible state can be modified by speculatively
executed instructions such as loads, such instructions should not
be tagged with their original source location information.
This would prevent the very annoying and unhelpful jumping around
the program during debugging.

The method I describe here, which roughly corresponds to the semantics
of Ada's "pragma Inspection_Point", seems relatively easy to implement
using an empty "asm" or similar.


PS. For convenience, I'm including a snippet of the Ada 2005 standard,
     the full version of which is freely available on the web.

H.3.2 Pragma Inspection_Point

1     An occurrence of a pragma Inspection_Point identifies a set of  
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.


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  
statement is allowed. Each object_name shall statically denote the  
of an object.

                               Static Semantics

5/2   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

                               Dynamic Semantics

6     Execution of a pragma Inspection_Point has no effect.

                          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).

                          Documentation Requirements

8     For each inspection point, the implementation shall identify a  
between each inspectable object and the machine resources (such as  
locations or registers) from which the object's value can be obtained.


9/2   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 read of each of its inspectable objects.

10    8  Inspection points are useful in maintaining a correspondence  
       the state of the program in source code terms, and the machine  
       during the program's execution. Assertions about the values of  
       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.

11    9  The identification of the mapping from source program objects  
       machine resources is allowed to be in the form of an annotated  
       listing, in human-readable or tool-processable form.

More information about the Gcc-patches mailing list