Version 1.9 Build 1367

News	FAQ
Search	Home

Up: No Title Previous: Installation

Verification

There was a protracted discussion concerning debugging strategies in the aips2-tools exploder. I do not intend to retrace all of the ground covered there, but simply propose a solution to the problems raised, the main one of which is that debugging optimized code is difficult for most existing debuggers, and impossible for some, for example Sun's. The only debugger which is claimed to work well at even the lowest level of optimization is Convex's CXdb, and even it seems less than perfect. However, given that optimizers for RISC machines can achieve a speedup of 100% or more, aips++ simply can't afford to do without it, Q-routine encapsulation not withstanding. An added complication is that the optimization may also introduce compiler-based bugs. The solution proposed here has been implemented in $\cal {A}$ IPS at the ATNF and appears to be quite workable. It is assumed that the working enviroment is one where aips++ is used simultaneously for production and development.

The idea is simply to have two sets of object libraries, one compiled optimized/no-debug, the other unoptimized/debug. The executables would normally be stored in optimized/no-debug form, but when debugging is required, it would be a simple matter to rebuild an executable in debug mode, since all libraries are present. Recompilation of static executables before debugging is good practice since it removes the possibility of an executable having been linked with a stale library. Debug executables would not normally be left in the system, and as set up at the ATNF, they are automatically deleted after three days.

If a compiler optimization bug is suspected, it should be a simple matter to do an unoptimized recompilation, rerun the task, and compare the output. If compiler optimization bugs are found, the offending functions may be added to a list of routines not to optimize.

Sharable libraries, if available, should only be used for the optimized executables. The debug libraries should be static for the following reasons

It avoids confusion. If several programmers were debugging a number of applications or functions independently, the last thing they'd want is to have sharable objects changing while they worked.
Since only a few executables should exist in debug form at any time, the use of sharable libraries is actually less efficient in terms of disk usage.

In other words, the two main features which make the use of sharable libraries attractive for the production system make them undesirable in the development system.

Some participants in the aips2-tools exploder felt it was important that it be possible to have a debugger start automatically from an exception handling routine. This can be done for the VMS debugger, but not so for any unix debuggers. Also, it may not be appropriate for users running an aips++ task to be thrown into a debugger automatically. A simple alternative would be for the exception handler simply to ask a question, thereby allowing time to start up a debugger and connect to the process. Something like

   "Exception xxx occurred, debugger may connect to
    process yyy now, otherwise hit <cr> to continue:"

Naturally this should only happen in interactive mode!

aips++ will have a set of coding standards which can be considered to be of two types, those of style and those of substance. The latter, which might include the use of C++ constructs that a putative lint++ would deal with, are beyond the scope of this discussion. The former, category includes what are sometimes called ``typing'' standards and deal with indentation, the placement of braces, and so on. Although it is also outside the scope of this document to define these standards, it is relevant to mention here the need for a tool which ensures that code conforms to, and if possible applies these standards. For example, a version of the indent utility exists which will format C++ code, and the aips++ typing standards could well be defined as a standard set of options to this utility.

A related topic is that of pretty-printing C and C++ source code. The tgrind utility is built on TEX and operates on plain source code. It uses different fonts to distinguish between comments, keywords, strings, and the rest. Although fairly limited in scope, tgrind does make source code more aesthetically pleasing and arguably easier to follow. Although it uses an unsuitable proportionally spaced TEX font by default, it can be modified to use the fixed-spaced Courier POSTSCRIPT font.

Up: No Title Previous: Installation