Elaboration in GNAT

Elaboration in GNAT

[Frode Tenneboe]

Using -gnatwa I get some elaboration issues with some legacy code in GNAT.
One of these are:

foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error
foo.adb:69:04: warning: missing pragma Elaborate_All for "bar"

The problem is that this crops up everywhere which I asume is because
the elboration of package bar is not very healthy.

The package in question uses Ada.Calendar, however there must be some
code in one (or more) of the dependencies in the body of bar which 
causes this. A manual inspection of this code is not done over night.

Is there a way of getting the information above a bit more verbose?

 -Frode
-- 
^ Frode Tenneb�                    | email: ft@edh.ericsson.se      ^
| Ericsson Radar AS. N-1788 Halden |                                |
| Phone: +47 69 21 41 47           | Frode@IRC                      |
| with Standard.Disclaimer; use Standard.Disclaimer;                |

Re: Elaboration in GNAT

[Mark Johnson]

Frode Tenneboe wrote:

> Using -gnatwa I get some elaboration issues with some legacy code in GNAT.
> One of these are:
>
> foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error
> foo.adb:69:04: warning: missing pragma Elaborate_All for "bar"
>
> The problem is that this crops up everywhere which I asume is because
> the elboration of package bar is not very healthy.
>
> The package in question uses Ada.Calendar, however there must be some
> code in one (or more) of the dependencies in the body of bar which
> causes this. A manual inspection of this code is not done over night.
>
> Is there a way of getting the information above a bit more verbose?

Not that I am aware of.

I had some lengthy discussions with Robert Dewar about this particular issue.
The warning basically says that elaboration code in the current package
depends upon another package. To be safe - elaborate the other package (and
all packages it depends upon) prior to elaboration of the current package. I
agree with the reasoning behind this so I have this warning turned on all
compiles we do as well.

Since I also demand warning free software in our facility, my "solution" is to
add pragma Elaborate_All(bar); in every place the warning is issued. That way
if we have any mutual dependencies [we haven't] they become compiler errors.
This is a quick solution and doesn't require any extensive analysis to put
into place.

Robert of course may give you slightly different suggestions. One that I tend
to ignore is to not use "gnatwa", but to specify exactly which warnings you
want and don't want. I have found over the last several months that added
warnings from gnatwa are beneficial and I'm sticking with it.

  --Mark

Re: Elaboration in GNAT

[Robert Dewar]

Frode Tenneboe <ft@alne.edh.ericsson.se> wrote in message news:<1006952193.650930@edh3>...
> Using -gnatwa I get some elaboration issues with some legacy code in GNAT.
> One of these are:
> 
> foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error
> foo.adb:69:04: warning: missing pragma Elaborate_All for "bar"
> Is there a way of getting the information above a bit
> more verbose?

If this message is not intelligible, I recommend reading
the entire chapter on elaboration issues in the users
guide. Elaboration is certainly a tricky issue, and 
generally you should not turn on -gnatwl unless you know
what you are doing.

We certainly find that helping customers work through
elaboration issues is a significant part of our support
effort, which is why we implemented the static model
of elaboration to try to ameliorate this in the future.

Re: Elaboration in GNAT

[Robert Dewar]

Mark Johnson <Mark_H_Johnson@Raytheon.com> wrote in message news:<3C052930.4FE65C5D@Raytheon.com>...
> Robert of course may give you slightly different 
> suggestions. One that I tend
> to ignore is to not use "gnatwa", but to specify exactly 
> which warnings you
> want and don't want. I have found over the last several 
> months that added
> warnings from gnatwa are beneficial and I'm sticking with 
> it.
> 
>   --Mark


That's fine, but you have to be prepared for new warnings
to pop up without warning, since we often add new warnings!

Re: Elaboration in GNAT

[Stephen Leake]

Frode Tenneboe <ft@alne.edh.ericsson.se> writes:

> Using -gnatwa I get some elaboration issues with some legacy code in GNAT.
> One of these are:
> 
> foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error
> foo.adb:69:04: warning: missing pragma Elaborate_All for "bar"

Can you edit the code? In that case, just add "pragma Elaborate_All
(bar);" in the context clause of foo.adb. Or, if you are using my
Emacs Ada mode extension gnat-fix-error.el, just hit C-f6, and this is
done for you :).

Hmm, apparently "Client" is a generic. In that case, it may be you
need the Elaborate_All in client.ads or client.adb; I'd have to see
the code, and re-read the manual, to be sure.

> The problem is that this crops up everywhere which I asume is
> because the elboration of package bar is not very healthy.

I'm not clear what you mean by "healthy". The precise meaning of this
error message is something like: "Some compilers may choose an
elaboration order that will elaborate 'foo' before 'bar'. In that
case, elaborating 'foo' will raise Program_Error".

The default mode of GNAT is to pick an elaboration order that avoids
this problem. The warning here is to help with porting to other compilers.

> The package in question uses Ada.Calendar, however there must be
> some code in one (or more) of the dependencies in the body of bar
> which causes this. A manual inspection of this code is not done over
> night.

I'm not clear why you think Ada.Calendar is relevant; it is not
mentioned in the error message (unless that's what 'foo' or 'bar'
really is).

> Is there a way of getting the information above a bit more verbose?

You need to read the chapters in the GNAT manual about elaboration; I
think you are confused (not surprising; elaboration can be confusing!).

Feel free to post a (small) example that gives this error.
> 
> 
>  -Frode -- ^ Frode Tenneb� | email: ft@edh.ericsson.se ^ | Ericsson
> Radar AS. N-1788 Halden | | | Phone: +47 69 21 41 47 | Frode@IRC | |
> with Standard.Disclaimer; use Standard.Disclaimer; |

-- 
-- Stephe

Re: Elaboration in GNAT

[Stephen Leake]

Frode Tenneboe <ft@alne.edh.ericsson.se> writes:

> Using -gnatwa I get some elaboration issues with some legacy code in GNAT.
> One of these are:
> 
> foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error
> foo.adb:69:04: warning: missing pragma Elaborate_All for "bar"

Can you edit the code? In that case, just add "pragma Elaborate_All
(bar);" in the context clause of foo.adb. Or, if you are using my
Emacs Ada mode extension gnat-fix-error.el, just hit C-f6, and this is
done for you :).

Hmm, apparently "Client" is a generic. In that case, it may be you
need the Elaborate_All in client.ads or client.adb; I'd have to see
the code, and re-read the manual, to be sure.

> The problem is that this crops up everywhere which I asume is
> because the elboration of package bar is not very healthy.

I'm not clear what you mean by "healthy". The precise meaning of this
error message is something like: "Some compilers may choose an
elaboration order that will elaborate 'foo' before 'bar'. In that
case, elaborating 'foo' will raise Program_Error".

The default mode of GNAT is to pick an elaboration order that avoids
this problem. The warning here is to help with porting to other compilers.

> The package in question uses Ada.Calendar, however there must be
> some code in one (or more) of the dependencies in the body of bar
> which causes this. A manual inspection of this code is not done over
> night.

I'm not clear why you think Ada.Calendar is relevant; it is not
mentioned in the error message (unless that's what 'foo' or 'bar'
really is).

> Is there a way of getting the information above a bit more verbose?

You need to read the chapters in the GNAT manual about elaboration; I
think you are confused (not surprising; elaboration can be confusing!).

Feel free to post a (small) example that gives this error.
> 
> 
>  -Frode -- ^ Frode Tenneb� | email: ft@edh.ericsson.se ^ | Ericsson
> Radar AS. N-1788 Halden | | | Phone: +47 69 21 41 47 | Frode@IRC | |
> with Standard.Disclaimer; use Standard.Disclaimer; |

-- 
-- Stephe

Re: Elaboration in GNAT

[Stephen Leake]

dewar@gnat.com (Robert Dewar) writes:

> Mark Johnson <Mark_H_Johnson@Raytheon.com> wrote in message news:<3C052930.4FE65C5D@Raytheon.com>...
> > Robert of course may give you slightly different 
> > suggestions. One that I tend
> > to ignore is to not use "gnatwa", but to specify exactly 
> > which warnings you
> > want and don't want. I have found over the last several 
> > months that added
> > warnings from gnatwa are beneficial and I'm sticking with 
> > it.
> > 
> >   --Mark
> 
> 
> That's fine, but you have to be prepared for new warnings
> to pop up without warning, since we often add new warnings!

This is true. However, they usually indicate true defects in my code.
I agree with Mark; my code gets better with each release of GNAT!

Keep up the good work, Robert :).

-- 
-- Stephe

Re: Elaboration in GNAT

[Simon Wright]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> Feel free to post a (small) example that gives this error.

My worst experience was with a 700-unit cycle (and although we were
supported, the code was classified)

Re: Elaboration in GNAT

[Frode Tenneboe]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=ISO, Size: 2651 bytes --]

Robert Dewar <dewar@gnat.com> wrote:
> Frode Tenneboe wrote:

>> Using -gnatwa I get some elaboration issues with some legacy code in GNAT.
>> One of these are:
>>
>> foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error
>> foo.adb:69:04: warning: missing pragma Elaborate_All for "bar"

> If this message is not intelligible, I recommend reading
> the entire chapter on elaboration issues in the users
> guide. Elaboration is certainly a tricky issue, and 
> generally you should not turn on -gnatwl unless you know
> what you are doing.

I like to _think_ I know what I'm doing. :) However, elaboration is 
tricky and I have read the relevant chapter several times. Every time
I read it I discover new neuances. I can only recomend everybody to 
read this chapter several times.

The code is legacy code with complex dependencies and need some time 
to grow..... The warning is removed by
adding (in the above example):

pragma Elaborate_Body(bar) 

in bar.ads.

However, I'm still not totatlly sure if this is the "correct"
approach. But at least it makes more sense than adding
pragma Elaborate_All in all clients using package bar.

> We certainly find that helping customers work through
> elaboration issues is a significant part of our support
> effort, which is why we implemented the static model
> of elaboration to try to ameliorate this in the future.

I think the elaboration performed by GNAT is very good,
especially considered when I tried to hand-elaborate a 
particular nasty piece of software it simply stops working. 
Even removing certain childs from packages which were not 
used there breaks the implementation.

However, I find the above warning a bit misplaced in my
case. I would have preferred:

bar.adb:69:04: warning: instantiation of "Client" may raise Program_Error
bar.adb:69:04: warning: missing pragma Elaborate_Body in spec

or:

bar.adb:69:04: warning: call to "Client" may raise Program_Error
bar.adb:69:04: warning: missing pragma Elaborate_Body in spec

I don't know if the compiler is able to detect this, but it would
be nicer. I'm also unsure if this is always true, but alternatively:

foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error
foo.adb:69:04: warning: missing pragma Elaborate_All for "bar" or
foo.adb:69:04: warning:  missing pragma Elaborate_Body in "bar"

 -Frode
-- 
^ Frode Tenneb�                    | email: ft@edh.ericsson.se      ^
| Ericsson Radar AS. N-1788 Halden |                                |
| Phone: +47 69 21 41 47           | Frode@IRC                      |
| with Standard.Disclaimer; use Standard.Disclaimer;                |

Re: Elaboration in GNAT

[Matthew Heaney]

"Frode Tenneboe" <ft@edh.ericsson.se> wrote in message
news:1010151875.216658@edh3...
> Robert Dewar <dewar@gnat.com> wrote:
> > If this message is not intelligible, I recommend reading
> > the entire chapter on elaboration issues in the users
> > guide. Elaboration is certainly a tricky issue, and
> > generally you should not turn on -gnatwl unless you know
> > what you are doing.

I'm not sure I agree with Robert's advice here.  I always use -gnatwl.

If you don't know what you're doing, then the best way to learn is to write
some programs and submit them to the compiler!

> The code is legacy code with complex dependencies and need some time
> to grow..... The warning is removed by adding (in the above example):
>
> pragma Elaborate_Body(bar)
>
> in bar.ads.
>
> However, I'm still not totatlly sure if this is the "correct"
> approach. But at least it makes more sense than adding
> pragma Elaborate_All in all clients using package bar.

My advice is to always use a categorization pragma in a package declaration,
and to use the strongest categorization possible, ie

1) pragma Pure;
2) pragma Preelaborate;
3) pragma Elaborate_Body;

The one time you cannot use a categorization pragma (say, Elaborate_Body) is
when a package withs its own children, which means a client will have to use
pragma Elaborate_All (if it needs to call operations in that package during
its own elaboration).

However, I prefer to restructure the parent package by moving the
child-dependent stuff into a new child, and then have that new child with
its siblings.  That makes it possible to say pragma Elaborate_Body in the
parent.

This comes up with you declare a "protocol class" (an abstract tagged type)
with a constructor to return a concrete type in the class:

package P is

   pragma Elaborate_Body; --illegal

   type T is abstract tagged limited null record;
   procedure Op (O : access T) is abstract;

   type T_Class_Access is access all T'Class;
   function New_T (S: String) return T_Class_Access;

end;

package P.C is
   type NT is new T with null record;
   procedure Op (O : access NT);
end;

with P.C;
package body P is
   function New_T (S : String) return T_Class_Acceess is
   begin
      return new P.C.NT;
   end;
end;

You can't use pragma Elaborate_Body in P, because the body of P withs its
own child P.C.  But the workaround is easy enough: simply declare the
constructor as a child of P:

function P.New_T (S : String) return T_Class_Access;

with P.C;
function P.New_T (S : String) return T_Class_Access is
begin
   return new P.C.NT;
end;

Now you can use pragma Elaborate_Body for P, because the body of P no longer
withs any of its children.

Re: Elaboration in GNAT

[Robert Dewar]

Frode Tenneboe <ft@edh.ericsson.se> wrote in message news:<1010151875.216658@edh3>...
> However, I find the above warning a bit misplaced in my
> case. I would have preferred:
> 
> bar.adb:69:04: warning: instantiation of "Client" may raise Program_Error
> bar.adb:69:04: warning: missing pragma Elaborate_Body in spec


Well perhaps you would have preferred that the compiler
tell you this, but it won't because it is wrong! The use
of a EB pragma in the spec is not an adequate solution
for this case!

> I'm also unsure if this is always true, but > 
> alternatively:

It is not always true

> foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error
> foo.adb:69:04: warning: missing pragma Elaborate_All for "bar" or
> foo.adb:69:04: warning:  missing pragma Elaborate_Body in "bar"


This is getting two separate things mixed up I am afraid.

Re: Elaboration in GNAT

[Robert Dewar]

"Matthew Heaney" <mheaney@on2.com> wrote in message news:<u3bh1tiuppk9c7@corp.supernews.com>...
> The one time you cannot use a categorization pragma (say, 
> Elaborate_Body) is
> when a package withs its own children, which means a 
> client will have to use
> pragma Elaborate_All (if it needs to call operations in 
> that package during
> its own elaboration).

I find the above incomprehensible. The normal case in which
you cannot use Elaborate_Body is when you have mutually
dependent packages, a common situation. It is simply
horrible to prohibit this common and perfectly reasonable
situation (the alternative is being forced to aggregate
packages which can perfectly well be separate).

Re: Elaboration in GNAT

[Robert Dewar]

Some things to remember here:

1. The static elaboration model of GNAT is primarily intended for the
development of new code.

2. If you are using GNAT in static mode, and do not intend
to port the code to other compilers, it is a waste of time
to mess around adding pragma Elaborate_All's, as was
correctly noted in this thread, the -gnatwl warning is
useful ONLY if you want to make sure that your code remains
portable to other compilers without worrying about elaboration order
messing things up.

3. If you are working with legacy code, it often makes no
sense to try to use the static model of GNAT, and you should simply
use -gnatE, and use the RM dynamic elaboration model. I am always
surprised by people who
are absolutely determined to beat legacy code into submission to the
GNAT static model. Yes, of course this
makes life easier in the future, but you have to be sure
it is worth the work.

4. If you are working with legacy code, which has complex
elaboration requirements, it is *highly* likely that the'
code has serious bugs in it -- namely it does not have all
the pragma Elaborate statements that should be there.

5. If you have buggy code of this kind, then you are between a rock
and a hard place.

rock = work required to meet GNAT static model
hard place = work required to stick in all the pragmas

It can often be very difficult to decide which way to go

But always remember that the GNAT static model is an
optional additional facility. It can never make porting
harder, because you can always proceed as though it is
not there.

The reason it is the default is so that those lucky Ada
programmers who know nothing about the horrors of elaboration who are
writing new code will find it impossible to dig themselves into
elaboration hell
unawares :-)

Robert Dewar

Re: Elaboration in GNAT

[Frode Tenneboe]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=ISO, Size: 1925 bytes --]

Robert Dewar <dewar@gnat.com> wrote:
> Frode Tenneboe <ft@edh.ericsson.se> wrote in message news:<1010151875.216658@edh3>...
>> However, I find the above warning a bit misplaced in my
>> case. I would have preferred:
>> 
>> bar.adb:69:04: warning: instantiation of "Client" may raise Program_Error
>> bar.adb:69:04: warning: missing pragma Elaborate_Body in spec

> Well perhaps you would have preferred that the compiler
> tell you this, but it won't because it is wrong! The use
> of a EB pragma in the spec is not an adequate solution
> for this case!

I realize that it is not necesarily true in all cases, but won't
the compiler be able to detect if pragma EB is appropriate?

I find the section starting with "The rule is simple.", second from
bottom on page 119 in the GNAT 3.13p UG to be quite concise.

>> I'm also unsure if this is always true, but > 
>> alternatively:

> It is not always true

My problems mainly comes from generic units which is repeatedly used
around everywhere with nesting, etc. If I start from the bottom and use
pure/preelaborate where possible and if the warning dissappears after 
using EB pragma - am I home safe?

>> foo.adb:69:04: warning: instantiation of "Client" may raise Program_Error
>> foo.adb:69:04: warning: missing pragma Elaborate_All for "bar" or
>> foo.adb:69:04: warning:  missing pragma Elaborate_Body in "bar"

> This is getting two separate things mixed up I am afraid.

Possibly - could you please elaborate? :)

I'm trying to convey that both solutions might solve the 'problem'. For 
the user the most desireable would (probably) be to fix the problem in 
the client.

 -Frode
-- 
^ Frode Tenneb�                    | email: ft@edh.ericsson.se      ^
| Ericsson Radar AS. N-1788 Halden |                                |
| Phone: +47 69 21 41 47           | Frode@IRC                      |
| with Standard.Disclaimer; use Standard.Disclaimer;                |

Re: Elaboration in GNAT

[Mark Johnson]

Robert Dewar wrote:
> 
> Some things to remember here:
> 
> 1. The static elaboration model of GNAT is primarily intended for the
> development of new code.
Hmm. I guess I disagree with that statement. See reasons below.

> [snip]
> 3. If you are working with legacy code, it often makes no
> sense to try to use the static model of GNAT, and you should simply
> use -gnatE, and use the RM dynamic elaboration model. I am always
> surprised by people who
> are absolutely determined to beat legacy code into submission to the
> GNAT static model. Yes, of course this
> makes life easier in the future, but you have to be sure
> it is worth the work.

Yes and no. Two examples follow.

The first example follows Robert's suggestion to use -gnatE. To predict
performance of our new system, we got a copy of ACES (Ada Compiler
Evaluation System) and ran several hundred of the test programs through
GNAT on the several target systems. Since this was a study and not
intended to be run operationally, we did not spend the time trying to
find and fix all the problems with this software. The use of -gnatE was
a good way to make progress without a lot of effort.

The second example is our real application. We are nearing the end of
porting a couple million lines of code from Apex & VADS to GNAT. We
actually have a small script that takes the compiler output, recognizes
the "pragma Elaborate_All" messages, and makes those changes
automatically. NONE of our software has broken when this was done. It
was relatively painless and easy to perform. I expect many other well
designed systems fall into this category.

The use of the warning of the compiler and the script to make the
changes has given us confidence that our code is free from any big
issues with elaboration. It is not a "big deal" to make the change in
most cases. As Robert's message goes on to say - complicated elaboration
code is likely filled with bugs anyway. I am glad we don't have this
kind of problem to worry about. 

--
  --Mark

Re: Elaboration in GNAT

[Robert Dewar]

Mark Johnson <Mark_H_Johnson@Raytheon.com> wrote in message news:<3C39D954.58672C0A@Raytheon.com>...
> Robert Dewar wrote:
> > 
> > Some things to remember here:
> > 
> > 1. The static elaboration model of GNAT is primarily intended for the development of new code.

> Hmm. I guess I disagree with that statement. See reasons 
> below.

You can't really disagree with the designer of a feature
telling you its primary design intention :-) Of course it
is just fine if it can be used for legacy code, and it is
always good to hear of such successes.

> > 3. If you are working with legacy code, it often makes 
> > no sense to try to use the static model of GNAT

Often /= never! My point, which I guess was confusing was
that it often does not make sense to put in a huge amount
of work to restructure code to meet the static model
 
> Yes and no. Two examples follow.

i.e. you are agreeing, sometimes yes, and sometimes no, 
which is exactly what I was saying

> As Robert's message goes on to say - complicated
> elaboration code is likely filled with bugs anyway. =

That's misreading my message, the bugs I was talking about
are failure to have all the pragma Elaborate's in place, 
but that is very specific.

The paradigm that causes most trouble with the static model
is:

    with X;
    package Y is
       ...
       Q : integer := X.Func;
       ...

where X is a giant package with a large number of with's,
but you happen to know that Func is a little function
that does not use any of these with's. So it is in fact
safe to use pragma Elaborate, instead of pragma Elaborate_All and
everything will work.

The coding philosophy of the static model of GNAT rejects
this coding style on the grounds that it is improper for
a client of X to know anything about the implementation
of the body of X (and any of its subprogram). Yes, that's
a legitimate coding philosophy, but that does not mean that
any code that does not follow this philosophy is buggy :-)

That being said, any program which does a lot of computation at
elaboration time is worrisome. That's
especially so if you have library tasks, which can
start up before elaboration is complete :-( (see special
section on elaboration and tasking in the GNAT docs).

Robert Dewar

Re: Elaboration in GNAT

[Robert A Duff]

dewar@gnat.com (Robert Dewar) writes:

> 4. If you are working with legacy code, which has complex
> elaboration requirements, it is *highly* likely that the'
> code has serious bugs in it -- namely it does not have all
> the pragma Elaborate statements that should be there.

True, but is it not also the case that these bugs are relatively
innocuous?  That is, if you forget your pragmas, then your program
usually blows up during elaboration (and you fix it), or else it doesn't
blow up (using this compiler).  That is, it's more of a *portability*
problem, than a problem of programs malfunctioning when users use them.

It sure is frustrating when you have to fiddle with those stupid
pragmas, but that is surely less costly than "real" bugs -- the ones
that find their way into the hands of your program's users.

Ideally, all elaboration problems would be detected at compile time (or
link time), and there would be no constraints on the structure of a
program due to elaboration-order issues.  Ada (even with GNAT's default
mode) does not achieve that, unfortunately.

- Bob

Re: Elaboration in GNAT

[Robert Dewar]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcc1ygx50tn.fsf@shell01.TheWorld.com>...
> True, but is it not also the case that these bugs are 
> relatively
> innocuous?  That is, if you forget your pragmas, then 
> your program
> usually blows up during elaboration (and you fix it), or 
> else it doesn't
> blow up (using this compiler).  That is, it's more of a 
> *portability*
> problem, than a problem of programs malfunctioning when 
> users use them.

In a large program, one with thousands of units, and millions of lines
of code, it can take weeks or months
of fiddling to find all the pragma Elaborate's that are
required, when you have to do a complete build to find
just one of them. Often in such a situation it may be
better to aim for the static solution off the bat.

> Ideally, all elaboration problems would be detected at 
> compile time (or
> link time), and there would be no constraints on the 
> structure of a
> program due to elaboration-order issues.  Ada (even with 
> GNAT's default
> mode) does not achieve that, unfortunately.

I understand that this is theoretically true, but in practice with
GNAT's static model problems do not arise.
We have not had one customer using the static model ever
run into any elaboration problems at all. So from a 
pragmatic point of view, the problem is solved.

Re: Elaboration in GNAT

[Robert A Duff]

dewar@gnat.com (Robert Dewar) writes:

> I understand that this is theoretically true, but in practice with
> GNAT's static model problems do not arise.
> We have not had one customer using the static model ever
> run into any elaboration problems at all.

I skept.  That is, I think you should say, "We have not had one customer
REPORT TO US ...."  :-)

- Bob

Re: Elaboration in GNAT

[Robert Dewar]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcck7up80yy.fsf@shell01.TheWorld.com>...
> dewar@gnat.com (Robert Dewar) writes:
> 
> > I understand that this is theoretically true, but in practice with
> > GNAT's static model problems do not arise.
> > We have not had one customer using the static model ever
> > run into any elaboration problems at all.
> 
> I skept.  That is, I think you should say, "We have not had one customer
> REPORT TO US ...."  :-)


Well as a competitor (who does not have this capability)
you may of course skept :-) :-)

But our supported customers are not shy about telling us
if they have any problems!

There is one kind of order of elaboration problem that
cannot be dealt with in any automatic manner, and is in
a sense completely outside the elaboration model, and that
is the situation in which the order of elaboration is
important not because of access-before-elaboration issues
(which is what the GNAT model is all about) but because of
other issues.

Consider a library declaration that says:

   x : integer := y.z;

where in package y there is

   y : integer := 35;

Now some other package z which has no elaboration relationship to x
whatsoever (i.e. it is not with'ed
by x and does no with x, directly or indirectly) has
a package body that says:

   y.z := 42;

Now the question is whether x gets initialized to 35 or
42, and that of course depends on when package z is 
elaborated. Either answer might be the intended "right"
one, and there is no clue in the sources at ALL about which
of these is right, so neither choice is better than the
other.

Naturally, GNAT has nothing to say about this issue (and
perhaps that is where Bob's "skept" comes from).

Note that even the Ada language is uncomfortable here, there is no way
for package x to demand that z be elaborated after itself, and even if
the desire is to
have it elaborated before, it is junky to have to add
a with for z just so that it can be mentioned in a pragma
Elaborate.

For a more complete description of this problem, see the
section "Other Elaboration Order Considerations" in the
GNAT users guide.

Actually the history of this section is interesting. We
thought at one time that we had a customer who had run into
this situation, but it turns out that it was something else, but still
it seemed worth generating the special section in the manual on this.

But the bottom line here is that elaboration has proved a
big issue for code using the dynamic elaboration model in
GNAT, in particular legacy code with missing pragma Elaborates, but
once the static model has been satisfied,
elaboration disappears as a significant issue in practice.
That's based on a lot of experience in working with hundreds of
million lines of legacy code from our customers.

Re: Elaboration in GNAT

[Robert Dewar]

Frode Tenneboe <ft@edh.ericsson.se> wrote in message news:<1010411468.548451@edh3>...
> I realize that it is not necesarily true in all cases, 
> but won't the compiler be able to detect if pragma EB is 
> appropriate?

No, because it cannot see the body in question
> 
> I find the section starting with "The rule is simple.", > 
> second from bottom on page 119 in the GNAT 3.13p UG to be 
> quite concise.

Well I don't have that version of the UG in front of me,
but if it is about EB, it is probably wrong. Early versions
of GNAT were definitely too ready to believe that the EB
pragma gave some useful guarantees when in fact it does not. It is not
better than a pragma Elaborate (as opposed
to Elaborate_All). 

If a package uses something at run time from an Elaborate_Body
package, then it cannot know what is
in the body, so in the general case you still need
a pragma Elaborate_All in such a case (and one will
be supplied automatically when using the GNAT standard
static approach).

Re: Elaboration in GNAT

[Arnaud Charlet]

<< True, but is it not also the case that these bugs are relatively
innocuous?  That is, if you forget your pragmas, then your program
usually blows up during elaboration (and you fix it), or else it doesn't
blow up (using this compiler).  That is, it's more of a *portability*
problem, than a problem of programs malfunctioning when users use them. >>

If you have library level tasks, that's definitely not true, since you can
have subtle
race conditions. And when you go from version n to version n+1 of your
favorite
compiler, you need to go and chase these bugs again.

Arno