Re: Debug code

Re: Debug code

[David Weller]

In article <1996Mar14.223326.13730@nosc.mil>,
Kelly J. Grant <grantk@manta.nosc.mil> wrote:
>> Jerry Blasdel (jblasdel@csc.com) wrote:
>> : I am tasked to add in debugging/diagnostic code
>> : into an existing ada application.  I would like
>> : to do somthing similar to a #ifdef DEBUG ... #endif
>> : like I would do in C but I did not think that Ada
>> : would let  me do anything like that.
>
>> : debug/diagnostic code that can remain in the
>> : source code.
>
>> comment out all lines with something like
>> --(DEBUG)  put_line("got to case #2");
>> we then run a nawk utility on the source code to enable debug messages
>> which effectively moves the cooment to the end of the line like:
>> put_line("got to case #2");  --(DEBUG)
>> there is of course another script to put it back at the beginning. It
>> is not as nice as defines but it works. Let me know if you find a better
>> way.
>
>
>That method is not bad, but there is a problem.  As soon as you recompile
>the source to include the new printouts, the problem may move or go away
>entirely (often while using addresses such as when using Windows or 
>other interfaces built using that *other* language :-)
>

The Ada 95 Booch Components takes a slightly different approach via
assertions.  While this lacks the expressiveness of "if DEBUG..."
sections of code, it certainly is helpful.

In certain "core" parts of the components, you'll find:
	pragma Assert ( This_Condition, "This condition not met");
(not verbatim, that was a simple example)

The result of that code, when assertions are turned on at compile
time, would be like an inlined "if" statement:

	if not This_Condition then
	   raise Assertion_Error; -- (with "This condition not met"
				  --  as the exception_string)
	end if;

While this introduces an element of non-portability, it has several
benefits:

1) It is a pragma, so compilers that don't support it will ignore it

2) It can be switched on during compilation, meaning you don't have to
touch the code

3) It minimizes the amount of "debug intrusion" in the actual code

Of course, the drawback is that if another vendor supports "pragma
Assert" in a different way, there might be an error :-)

All in all, I've found this feature to be enormously powerful.  I only
regret that it couldn't make it into the standard (yet :-)

-- 
		    GNAT = GNAT is Not an Ada Translator
==Ada 95 Booch Components: www.ocsystems.com/booch or www.dfw.net/~dweller==
Reality: Work, Work, Work, Guitar.         | Plugged: Fender Telecaster Deluxe
Fantasy: Guitar, Guitar, Guitar, Work(ha!) | Unplugged: Yamaha CG-150SA

Re: Debug code

[Robert Dewar]

Dave Weller said

"All in all, I've found this feature to be enormously powerful.  I only
regret that it couldn't make it into the standard (yet :-)"

talking of the GNAT pragma Assert. Actually thre are good reasons why
this is not in the standard. It is surprisingly quite difficult to define
exactly from a semantic point of view (the issue is that if it really is
equivalent to the if from a formal semantic point of view, then the
compiler could draw conclusions from its existence and affect code 
outside the Assert which you don't want. Avoiding such effects is (a)
difficult to formally define and (b) in some environments difficult to
implement.

Still it seems likely that other Ada 95 compilers will simply copy this
useful pragma, so the de facto effect of standardization may be achieved
anyway!

Another GNAT pragma is pragma Debug. 

	pragma Debug (procedure call);

e.g.

	pragma Debug (Put_Line ("got to point 32"));

This can occur either in a declarative part or a statement part, and like
pragma Assert is controlled by the -gnata switch of GNAT. If -gnata is
off, the pragma is ignored, if -gnata is set, it is equivalent to the
procedure call (the ability to get print statements into declarative
parts is particularly handy).

Note to the formalists: this pragma is a bit dubious, since semantically
the argument is not an expression, but it is syntactically an expression,
so strictly it is an acceptable, though odd, addition. This oddness may
however introduce implementatoin difficulties, so I am not quite as sure
this pragma will be copied (of course other implementations should then
ignore it at least).

By the way, although both pragma Assert and Debug feel like statements,
syntatically they are not, so you cannot write

	else
	   pragma Assert ( ....);
        end if;

you need a null statement:

	else
	   pragma Assert ( ...); null;
        end if;

Incidentally the GNAT source is full of pragma Assert statements, which is
why the current front end is very slow compared to what it will be in a
future release.

Re: Debug code

[Robert A Duff]

In article <dewar.827152644@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>... Actually thre are good reasons why
>this is not in the standard.

I disagree.

>... It is surprisingly quite difficult to define
>exactly from a semantic point of view (the issue is that if it really is
>equivalent to the if from a formal semantic point of view, then the
>compiler could draw conclusions from its existence and affect code 
>outside the Assert which you don't want.

I disagree.  I think this is exactly what you *do* want.  In this
regard, I see no difference between "pragma Assert(X <= 10);" and a
normal range check, as for "X: Integer range 1..100;".  IMHO, the pragma
should be *exactly* semantically equivalent to an if_statement.  (It's
not syntactically equivalent, because you can't put an if_statement in a
package spec.)  If you turn the pragma off, it should be *exactly*
semantically equivalent to a null_statement.

(I realize that Asserts can contain side effects, but that unfortunate
fact does not change my mind on this point.)

>you need a null statement:
>
>	else
>	   pragma Assert ( ...); null;
>        end if;

Yuck.  I regularly have to compile my code twice after inserting an
Assert, because of this Ada silliness.

>Incidentally the GNAT source is full of pragma Assert statements, which is
>why the current front end is very slow compared to what it will be in a
>future release.

Have you measured this?  Even if you're not ready to turn them off, it
would be interesting to try it just once, to see how much speed could be
gained by turning them off.

- Bob

Re: Debug code

[Norman H. Cohen]

In article <dewar.827166947@schonberg>, dewar@cs.nyu.edu (Robert Dewar)
writes about turning off assertions: 

|>                                                                  We have
|> done it much more than once, and have a pretty good idea of how much
|> time it saves in the front end (hint: substantial :-)

Not surprising.  In the project I'm currently working on, we have no
compunctions about adding assertions that invoke O(n**2) functions to
check the overall validity of a large and complex data structure.
Does wonders for assigning blame for a bug to a particular phase of the
program!

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Debug code

[Bob Kitzberger]

Kelly J. Grant (grantk@manta.nosc.mil) wrote:

: I'm also a big fan of providing methods like  Show( title, value ),
: with overloads for various types to use for displaying values, such as
: integer, string and boolean.  Leave all this code in during
: development, and when you deliver, you could replace the package debug
: body with no-op functions (with a pragma INLINE), and you then won't
: pay a performance penalty.  It is also handy to add a defaulted parameter
: at the end with a boolean to indicate whether or not to add a new_line
: for times when you want multiple values on the same line.

Along a similar vein... I find it useful to define a Image function
for ADTs:

  package Pencil is
    type Object is private;
    function Image( The_Object : Object ) return String;
  ...

Force of habit, it usually only takes a minute to write an Image
function for a new ADT, and it comes in surprisingly handy
for inclusion in a debug setup like you describe above.  I find
defining a function that returns a string is more flexible than
defining a subprogram that writes to stdout, e.g.

--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com

Re: Debug Code

[Sundog Software]

BD>will become a de-facto standard.  I hope.  Any other compiler vendors
BD>care to comment?

DW>While this introduces an element of non-portability, it has several
DW>benefits:
Seems like this Pragma Assert does not allow having type's and other
declarations for use only by the debug code (not present in the
release code/data).  We tend to utilize a command line switch that set's
the '@' to be treated as a space or as "--" to allow arbitrary insertions.
For example :
    Type Forward_Type_Reference Is Record
@       Old_Forward, Old_Type_Index : Type_Ptr; -- only for debuging !!
        Full_Def : Boolean;
        New_Type_Index : Type_Ptr;
        Next : Forward_Type_Ptr;
    End Record;
    ...
    Procedure Save_Forward_Type_Reference(  Full_Def : In Boolean;
                                          @ Old_Forward,
                                          @ Old_Type_Index,
                                            New_Type_Index : In Type_Ptr) Is
    ...
                Save_Forward_Type_Reference(@ Old_Forward => From.Class_Type,
                                            @ Old_Type_Index => From_Index,
                                              Full_Def => FALSE,
                                              New_Type_Index => To_Index);

>Another GNAT pragma is pragma Debug.
>        pragma Debug (procedure call);
RD>This can occur either in a declarative part or a statement part, and like
RD>pragma Assert is controlled by the -gnata switch of GNAT. If -gnata is

Declarative part for a procedure call ?

Typically my compiler debug code looks like :

@           If J2Trace.Symbol_Trace(J2Trace.J2INST) Then
@               J2Trace.Put_Line("make entry result is");
@               J2Dump_Symbols.Dump_Sym_Info(Symbol, TRUE, FALSE);
@           --Else no trace
@           End If;

or in very painfull spots nested if's (and then could be used) :
@           If J2Trace.Symbol_Trace(J2Trace.J2SYMLOA) Then
@               If J2Trace.Drastic("With_Code bottom " &
@                  Pas1Info.Get_Id(With_Info.Unit_At.Identifier)) Then
@                   J2Dump_Symbols.Dump_Symboltable(FALSE);
@               --Else skip
@               End If;
@           --Else no trace
@           End If;
Which seems like a pain to convert each of these into procedure's and rely
on code-trimming to remove the unused debug code. (On my non-RR projects the
conditional is normally not a function call so I can RELY ON CODE-TRIMMING
along with a per module trace variable that requires editing to change).
I would think that Pragma Debug would be painfull for GNAT since I am
not aware of a code trimming option or unused data optimization.


Sundog.Software@Msn.FullFeed.Com

Re: Debug Code

[Robert Dewar]

Sundog said

"Which seems like a pain to convert each of these into procedure's and rely
on code-trimming to remove the unused debug code. (On my non-RR projects the
conditional is normally not a function call so I can RELY ON CODE-TRIMMING
along with a per module trace variable that requires editing to change).
I would think that Pragma Debug would be painfull for GNAT since I am
not aware of a code trimming option or unused data optimization."

Whether or not you get removal of unused subprograms right now with GNAT
is an OS issue, not a GNAT issue. For example, in AIX it comes for
free. That's a pity, but is part of the price to pay for following
system standards closely (note that C does not get code trimming either
in most Unix environments). It's less of a concern than it used to be
in the days of 640K memories :-)

We do have a scheme for OS independnet removal of unused subprorams, but
it is not going to appear in the next week or two!

Pragma Debug cannot be particularly painful, sice it is an optional
addition that you should not use if it causes you pain :-)

It is of course perfectly reasonable to use some extrnal preprocessor
to provide for full conditional compilation if that's what you really
want (it's not something I would ever want to do, but there are those
who do!)

Debug Code

[Jerry Blasdel]

I am tasked to add in debugging/diagnostic code
into an existing ada application.  I would like 
to do somthing similar to a #ifdef DEBUG ... #endif
like I would do in C but I did not think that Ada 
would let  me do anything like that.  

Does anyone have any good ways to incorporate 
debug/diagnostic code that can remain in the 
source code.


Thanks,

JB.