Conditional compilation of debug traces without cpp

Conditional compilation of debug traces without cpp

[guillaume.portail]

Hi,

I have pieces of code like this (please just follow the general idea and 
forgive syntax errors) :

package Debug is
   procedure Put_Line (M : in String);
end;

package body Debug is
   Enabled : constant Boolean := False;
   procedure Put_Line (M : in String) is
   begin
     if Enabled then
       Real_Put_Line (M);
     end;
   end;
end;

Many other units, many calls like :
   ...
   Debug.Put_Line ("PC was here, A = ", A_Type'Image(A));  -- (1)
   ...

Debug.Enabled is a compile time constant, so with a bit of -O3 pragma 
Inline or other (-gnatN), the binary implementation of Debug.Put_Line 
will be null. But never will be the elaboration of the many calls to it. 
I guess that the elaboration of theses calls is always required by the 
language, think of :
   Debug.Put_Line ("PC was here, A = " & A_Function_Call(12));  -- (2)
   Debug.Put_Line ("PC was here, A = " & A_Function_Call(1/0)); -- (3)
For my need, A_Function_Call is only for debugging purpose here, it has 
no side effect (it is a function).

How may I organize the code to obtain the effect of having Debug.* calls 
being nulls when Debug.Enabled is False ?

For your information, this is easy using cpp :

#if _DEBUG
#define DEBUG(x)	real_put_line x
#else
#define DEBUG(x)	0
...
   if (foo)
   {
     a = something;
     DEBUG(("PC was here, A=%d", b()+a));
   }
   else
     DEBUG(("no foo"));
...

And I would like not to use cpp or gnatprep, etc.

What is the trick ?
--
Thierry Bernier

Re: Conditional compilation of debug traces without cpp

[Ludovic Brenta]

guillaume.portail@grospied.enanglais.com writes:
> How may I organize the code to obtain the effect of having Debug.*
> calls being nulls when Debug.Enabled is False ?

You could place all calls to Debug.Put_Line inside a pragma Debug.
These are enabled only if you pass -gnata to GNAT; they are off by
default.

HTH

-- 
Ludovic Brenta.

Re: Conditional compilation of debug traces without cpp

[guillaume.portail]

Ludovic Brenta wrote:

> You could place all calls to Debug.Put_Line inside a pragma Debug.
> These are enabled only if you pass -gnata to GNAT; they are off by
> default.
> 
> HTH

It helps, but it is GNAT specific. I would prefer a pure Ada solution.

--
Thierry Bernier

Re: Conditional compilation of debug traces without cpp

[Gautier]

At least this works, with GNAT 3.15p and ObjectAda 7.2.2 SE:

package Debug is
   procedure Put_Line (M : in String);
   pragma Inline(Put_Line);
   procedure Put_Line (M : in String; I: Integer);
   pragma Inline(Put_Line);
end Debug;

with Ada.Text_IO;
package body Debug is
   Enabled : constant Boolean := False;
   procedure Put_Line (M : in String) is
   begin
     if Enabled then
       Ada.Text_IO.Put_Line (M);
     end if;
   end;
   procedure Put_Line (M : in String; I: Integer) is
   begin
     if Enabled then
       Ada.Text_IO.Put_Line (M & Integer'Image(I));
     end if;
   end;
end Debug;

with Debug, Ada.Text_IO;
procedure Test_debug is
begin
   for I in 1..1234 loop
     Ada.Text_IO.Put_Line("[a]");
     Debug.Put_Line ("(0) PC was here");           -- (0)
     Debug.Put_Line ("(1) PC was here, I = ", I);  -- (1)
     Ada.Text_IO.Put_Line("[b]");
   end loop;
end;

gcc -O2 -S -gnatpN test_debug.adb

	.file	"test_debug.adb"
gcc2_compiled.:
___gnu_compiled_ada:
.text
LC0:
	.ascii "[a]"
	.align 4
LC1:
	.long 1
	.long 3
LC2:
	.ascii "(0) PC was here"
_C7b.0:
	.ascii "(1) PC was here, I = "
LC3:
	.ascii "[b]"
	.align 4
.globl __ada_test_debug
__ada_test_debug:
	pushl %ebp
	movl %esp,%ebp
	pushl %ebx
	movl $1,%ebx
	.align 2,0x90
L37:
	movl $LC0,%eax
	movl $LC1,%edx
	pushl %edx
	pushl %eax
	call _ada__text_io__put_line$2
	movl $LC3,%eax
	movl $LC1,%edx
	pushl %edx
	pushl %eax
	call _ada__text_io__put_line$2
	addl $16,%esp
	incl %ebx
	cmpl $1234,%ebx
	jle L37
	movl -4(%ebp),%ebx
	movl %ebp,%esp
	popl %ebp
	ret

As you see, it does nothing else than writing the [a] and [b].
Similar thing for ObjectAda (Release mode).
When you have concatenations and/or a function call in the parameter 
it doesn't work with these compilers - maybe, as you guess, they can't 
skip the computation of parameters. Or they may, or newer versions do.
Perhaps it is a question of having a pragma Pure for the function.
HTH, Gautier
_______________________________________________________________
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Conditional compilation of debug traces without cpp

[Simon Wright]

guillaume.portail@grospied.enanglais.com writes:

> Debug.Enabled is a compile time constant, so with a bit of -O3 pragma
> Inline or other (-gnatN), the binary implementation of Debug.Put_Line
> will be null.

I don't think you need more than -O2 for this magic to work. But it's
a promise made by GNAT, other compilers may behave differently.

You could check out gnatprep, I suppose.

Re: Conditional compilation of debug traces without cpp

[Björn Persson]

guillaume.portail@grospied.enanglais.com skrev:
> Ludovic Brenta wrote:
>> You could place all calls to Debug.Put_Line inside a pragma Debug.
> 
> It helps, but it is GNAT specific. I would prefer a pure Ada solution.

Well, there is always the good old if statement:

with Ada.Text_IO; use Ada.Text_IO;
procedure Debug_Demo is
    Debug_Enabled: constant Boolean := false;
begin
    if Debug_Enabled then
       Put_Line("PC was here, A = " & Integer'Image(12));
    end if;
end Debug_Demo;

When Debug_Enabled is false, the compiler (at least Gnat) will remove 
the if statement completely.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Conditional compilation of debug traces without cpp

[guillaume.portail]

Bj�rn Persson wrote:

> Well, there is always the good old if statement:

This complicates the code (the McCabe numbers), it is better to have the 
if statement encapsulated.

--
Thierry Bernier

Re: Conditional compilation of debug traces without cpp

[Björn Persson]

guillaume.portail@grospied.enanglais.com wrote:
> Bj�rn Persson wrote:
>> Well, there is always the good old if statement:
> 
> This complicates the code (the McCabe numbers), it is better to have the 
> if statement encapsulated.

I see. So you're looking for a trick to do the same thing in a more 
convoluted way so that the McCabe thingy won't notice it. :-)

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Conditional compilation of debug traces without cpp

[Matthew Goulet]

guillaume.portail@grospied.enanglais.com wrote:
> Ludovic Brenta wrote:
>
> > You could place all calls to Debug.Put_Line inside a pragma Debug.
> > These are enabled only if you pass -gnata to GNAT; they are off by
> > default.
> >
> > HTH
>
> It helps, but it is GNAT specific. I would prefer a pure Ada solution.
>
> --
> Thierry Bernier

AFAIK the reference manual specifies unknown pragmas should be ignored,
so if development is done on GNAT pragma Debug could be used, and
they'd be ignored on other compilers (sort of the desired effect).  Not
exactly compiler agnostic, but a thought.

-Matt

Re: Conditional compilation of debug traces without cpp

[Jean-Pierre Rosen]

guillaume.portail@grospied.enanglais.com a �crit :
> package Debug is
>   procedure Put_Line (M : in String);
> end;
> 
> package body Debug is
>   Enabled : constant Boolean := False;
>   procedure Put_Line (M : in String) is
>   begin
>     if Enabled then
>       Real_Put_Line (M);
>     end;
>   end;
> end;
Small plug: have a look at package Debug from Adalog's components page 
(http://www.adalog.fr/compo2.htm), it does this in a very sophistciated 
way...

As for your question:
> How may I organize the code to obtain the effect of having Debug.* calls 
> being nulls when Debug.Enabled is False ?
> 
Name you package Debug_Effective. Then write another package 
(Debug_Dummy) with the same specification, and where all procedures are 
null. Then simply compile:

with Debug_Effective;
package Debug renames Debug_Effective;

or:
with Debug_Dummy;
package Debug renames Debug_Dummy;

Switching packages is then not more difficult than changing a #define...

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Conditional compilation of debug traces without cpp

[guillaume.portail]

Jean-Pierre Rosen wrote:

> Switching packages is then not more difficult than changing a #define...

Nice, thank you ! And thank you for your Debug package, I already know 
about it.

But don't you think that the elaboration of the calls will still exist ?
Executing the statement :

	Null_Proc ("I was here" & Function_Call(A+12));

will always produce a call to Function_Call, even if Null_Proc has a 
null body, I guess.
I have zillion of 'complicated' traces like this :

	Traces.Put_Info ("Mouse at home, ears=" & (+Mice.ears)
                                       & "tong=" & (+Mice.tong)
                                       ...
                                       & "legs=" & (+Mice.legs));

where "+" is a rename of some kind of 'Image, may be a sophisticated 
one. In general returning fixed-length strings, but not always. So I 
suspect that theses traces call every "+" involved in the elaboration of 
the call, maybe doing heap allocation, even when Trace.Put_info is null.

--
Thierry bernier

Re: Conditional compilation of debug traces without cpp

[Martin Krischik]

guillaume.portail@grospied.enanglais.com wrote:
> Jean-Pierre Rosen wrote:
>
> > Switching packages is then not more difficult than changing a #define...
>
> Nice, thank you ! And thank you for your Debug package, I already know
> about it.
>
> But don't you think that the elaboration of the calls will still exist ?
> Executing the statement :
>
> 	Null_Proc ("I was here" & Function_Call(A+12));
>
> will always produce a call to Function_Call, even if Null_Proc has a
> null body, I guess.
> I have zillion of 'complicated' traces like this :
>
> 	Traces.Put_Info ("Mouse at home, ears=" & (+Mice.ears)
>                                        & "tong=" & (+Mice.tong)
>                                        ...
>                                        & "legs=" & (+Mice.legs));
>
> where "+" is a rename of some kind of 'Image, may be a sophisticated
> one. In general returning fixed-length strings, but not always. So I
> suspect that theses traces call every "+" involved in the elaboration of
> the call, maybe doing heap allocation, even when Trace.Put_info is null.

Indeed. For simple cases "-O3" and "pragma Inline" will help. For GNAT
you can take it furher with pragma "Pure_Function" but you are right:
eventually you reach the point where functions will be called even when
the result is not needed.

You could use "GNAT PREPROCESS" - which gives you the same solution as
C/C++: a text preprocessor. With all the advantages and disadvantages.
Well not quite: "GNAT PREPROCESS" writes the preprocessed file to the
drive - which has it's own set advantages and disadvantages.

Martin

Re: Conditional compilation of debug traces without cpp

[Jean-Pierre Rosen]

guillaume.portail@grospied.enanglais.com a �crit :
> Jean-Pierre Rosen wrote:
> 
>> Switching packages is then not more difficult than changing a #define...
> 
> Nice, thank you ! And thank you for your Debug package, I already know 
> about it.
Forgot to mention: make the fake debug pure, to avoid any elaboration.

> But don't you think that the elaboration of the calls will still exist ?
> Executing the statement :
> 
>     Null_Proc ("I was here" & Function_Call(A+12));
> 
> will always produce a call to Function_Call, even if Null_Proc has a 
> null body, I guess.
Don't want to be pedantic, but just to make sure there is no confustion:
- A declaration is elaborated
- A statement is executed
- An expression is evaluated

Therefore yes, the *execution*  of the call will always involve the 
*evaluation* of the parameters (unless the compiler can prove that this 
evaluation has no side-effects - like a call to a function declared in a 
pure package).
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Conditional compilation of debug traces without cpp

[guillaume.portail]

Jean-Pierre Rosen wrote:

> Therefore yes, the *execution*  of the call will always involve the 
> *evaluation* of the parameters (unless the compiler can prove that this 
> evaluation has no side-effects - like a call to a function declared in a 
> pure package).

Ah yes, I just read LRM95-10.2.1(18), it seems to be what I want (I 
forgot this point). But Pure is applicable only to library units. And I 
need to apply it to functions of packages :

package Data is
   type T is private
   procedure ...
private
   type T is ...
end;

package Data.Image
   subtype T_String is String(...);
   function "+" (R : T) return T_String;
   ...
end;


- Data.Image."+" has really no side effect, but it cannot be declared 
Pure. Why ? The legality of such a pragma seems statically computable 
(the body of "+" should not access 'global' variables, etc).
- "+" is located in its own package, where UI resources are grouped, as 
to facilitate their potential elimination/counting (all are named 
*.*...*.Image).

--
Thierry Bernier

Re: Conditional compilation of debug traces without cpp

[Matthew Goulet]

guillaume.portail@grospied.enanglais.com wrote:
> Jean-Pierre Rosen wrote:
>
> > Therefore yes, the *execution*  of the call will always involve the
> > *evaluation* of the parameters (unless the compiler can prove that this
> > evaluation has no side-effects - like a call to a function declared in a
> > pure package).
>
> Ah yes, I just read LRM95-10.2.1(18), it seems to be what I want (I
> forgot this point). But Pure is applicable only to library units. And I
> need to apply it to functions of packages :
>
> package Data is
>    type T is private
>    procedure ...
> private
>    type T is ...
> end;
>
> package Data.Image
>    subtype T_String is String(...);
>    function "+" (R : T) return T_String;
>    ...
> end;
>
>
> - Data.Image."+" has really no side effect, but it cannot be declared
> Pure. Why ? The legality of such a pragma seems statically computable
> (the body of "+" should not access 'global' variables, etc).
> - "+" is located in its own package, where UI resources are grouped, as
> to facilitate their potential elimination/counting (all are named
> *.*...*.Image).

Perhaps I misunderstand what you are saying, but declaring the packages
Pure means that the functions and procedures in them are also Pure.
So, if Data and Data.Image were Pure, so should "+", even though pragma
Pure cannot be applied to "+" directly.

There is also the new pragma Pure_Function, but I cannot recall off the
top of my head if it can be used outside of the context of a pure
package.

-Matt

Re: Conditional compilation of debug traces without cpp

[Stephen Leake]

"Martin Krischik" <krischik@users.sourceforge.net> writes:

> You could use "GNAT PREPROCESS" - which gives you the same solution as
> C/C++: a text preprocessor. With all the advantages and disadvantages.
> Well not quite: "GNAT PREPROCESS" writes the preprocessed file to the
> drive - which has it's own set advantages and disadvantages.

You seem to be implying that the C preprocessor does not write the
intermediate file to the disk.

The Gnu C preprocessor _does_ write the intermediate file, and deletes
it when it is done compiling. There is an option to preserve the file. 

I guess other C compilers could do it differently, and not use the
disk.

In any case, the act of writing the file to the disk is transparent to
the user, unless the option to preserve it is given. This transparency
is provided by gcc; it runs the preprocessor on _all_ files (as
required by the C standard), and it knows the naming conventions for
the original and preprocessed files.

In GNAT, the use of preprocessed files is not so transparent, because
gnatmake does not know how to run the preprocessor. 

In addition, you need different naming conventions for the original
and preprocessed files. If the preprocessed files follow the GNAT
convention (the simplest choice), then the editing environment (Emacs
or GPS or AdaGIDE) will still not understand the naming convention for
the original files.

With a proper makefile, you can run the GNAT preprocessor on _all_
files. If you use the GNAT default naming convention for the original
files (so the editor works nicely), and tell GNAT to use an alternate
naming convention for the preprocessed files (via project files),
using the GNAT preprocessor will be as transparent as using the Gnu C
preprocessor.

-- 
-- Stephe

Re: Conditional compilation of debug traces without cpp

[Thierry Bernier]

Matthew Goulet wrote:

> Perhaps I misunderstand what you are saying, but declaring the packages
> Pure means that the functions and procedures in them are also Pure.

I know.

> So, if Data and Data.Image were Pure, so should "+", even though pragma
> Pure cannot be applied to "+" directly.

Pure is a property that most of the packages can not have.

> There is also the new pragma Pure_Function, but I cannot recall off the
> top of my head if it can be used outside of the context of a pure
> package.

Are you sure it is not implementation specific (GNAT may be ?) ? I can't 
find it in the ARM05-L.

--
Thierry Bernier

Re: Conditional compilation of debug traces without cpp

[M E Leypold]

Stephen Leake <stephen_leake@acm.org> writes:

> In GNAT, the use of preprocessed files is not so transparent, because
> gnatmake does not know how to run the preprocessor. 

This has already annoyed me a number of times. I'd have liked to use
gnatmake exclusively, but because of this I've been forced to wrap a
Unix Makefile around gnatmake which will first do all preprocessing
before invoking gnatmake. Ugly.


> In addition, you need different naming conventions for the original
> and preprocessed files. If the preprocessed files follow the GNAT
> convention (the simplest choice), then the editing environment (Emacs
> or GPS or AdaGIDE) will still not understand the naming convention for
> the original files.

A way around this is, to store the not preprocessed files in a
subdirectory and let them have the same suffices as the Ada sources.

For instance, the perprocessor input for foo.adb would live in
template/foo.adb. When using Unix make, a rule like

template/%.adb: %.adb
        ... preprocess ...

can take care of the preprocessing.

> With a proper makefile, you can run the GNAT preprocessor on _all_
> files.  If you use the GNAT default naming convention for the
> original files (so the editor works nicely), and tell GNAT to use an
> alternate naming convention for the preprocessed files (via project
> files), using the GNAT preprocessor will be as transparent as using
> the Gnu C preprocessor.

This is another interesting approach. Probably better than mine. Thanks.

Regards -- Markus

Re: Conditional compilation of debug traces without cpp

[Randy Brukardt]

"Matthew Goulet" <blueherring0@gmail.com> wrote in message
news:1152248447.796179.305520@s13g2000cwa.googlegroups.com...
> guillaume.portail@grospied.enanglais.com wrote:
...
> There is also the new pragma Pure_Function, but I cannot recall off the
> top of my head if it can be used outside of the context of a pure
> package.

Pure_Function is GNAT-specific. It was studied for inclusion in Ada 2005,
but ultimately it was not included. (The problem was that the GNAT pragma is
an assertion of purity, which is not checked. Some reviewers prefered a
version that imposed actual requirements on the subprogram. We weren't able
to resolve the debate.)

                       Randy.