GNAT internals question

GNAT internals question

[sk]

Hi, 

I have recently been looking at the code generated by 
the "gcc -S ..." assembly listing of the binding file 
for an Ada main and a "phantom" function "ada_main___elabs" 
appears.

Using "objdump" to view the final object code, the function
also appears.

However, I cannot find where and under what circumatances 
"ada_main___elabs" is referenced or called.

Does anyone have experience of "ada_main___elabs" and be
willing to share this information ?

Also, any knowledge or "gotchas" concerning the GNAT
"pragma No_Run_Time" ?

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: GNAT internals question

[Stephen Leake]

sk <sknipe@ktc.com> writes:

> Also, any knowledge or "gotchas" concerning the GNAT
> "pragma No_Run_Time" ?

I've just started using it. It seems to work.

There are a couple constructs that apparently require run-time support
that the pragma does not catch; mainly to do with returning
unconstrained arrays on the stack (like function foo return string).
I discovered those missing functions at link time; it wasn't too hard
to find the offending constructs.

If your actual OS supports those constructs, you won't notice this.

I guess I should put in a bug report, but I did this on an unsupported
platform, and I'm not paying for support for No_Run_Time, so I haven't
yet :).

-- 
-- Stephe

Re: GNAT internals question

[sk]

Hi,

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>
> ... unconstrained arrays on the stack ...
> ... those missing functions at link time ...

That is my experience also so far with the addition 
of the error message "No run time does not support 
this construct" from the compiler.

As you say, the problems so far are quickly isolated 
by the linker, I am interested in hearing of any shark 
attack type biting which will catch me totally, sneekily
and silently :-).

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: GNAT internals question

[David C. Hoos, Sr.]

Interesting.

I looked at all of my object files containing Ada_Main packages --
i.e. all b~*.o files -- and found only ada_main___elabb -- not a
single instance of ada_main___elabs.

Can you supply an example?

I suspect that the ada_main_elabb is never called, because looking
at the source code for the Ada_Main packages, I could see nothing
that would require elaboration code to be generated.  The compiler
probably always generates a stub for body elaboration, but never
calls it because it would do nothing.
  
----- Original Message ----- 
From: "sk" <sknipe@ktc.com>
To: <comp.lang.ada@ada.eu.org>
Sent: June 26, 2002 6:50 AM
Subject: GNAT internals question


> Hi, 
> 
> I have recently been looking at the code generated by 
> the "gcc -S ..." assembly listing of the binding file 
> for an Ada main and a "phantom" function "ada_main___elabs" 
> appears.
> 
> Using "objdump" to view the final object code, the function
> also appears.
> 
> However, I cannot find where and under what circumatances 
> "ada_main___elabs" is referenced or called.
> 
> Does anyone have experience of "ada_main___elabs" and be
> willing to share this information ?
> 
> Also, any knowledge or "gotchas" concerning the GNAT
> "pragma No_Run_Time" ?
> 
> -- 
> -------------------------------------
> -- Merge vertically for real address
> -------------------------------------
> s n p @ t . o
>  k i e k c c m
> -------------------------------------
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

Re: GNAT internals question

[sk]

Hi,

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com>
> ... not a single instance of ada_main___elabs.

Sorry, I mis-remembered, it is "ada_main___elabb" 
I am refering to.

So far my experience is also that it is not called 
but that doesn't mean that it never is used. 

It is difficult for me to describe what I am asking,
but ...

procedure Nothing is
begin
    null;
end Nothing;

The pragmas are to remove all external references
and dependencies on the GNAT runtime.

Linux shell commands :

    gnatmake -c -v nothing
    gnatbind -v nothing 
    gcc -v -c -S b~nothing.adb

producing "b~nothing.s" which contains the elusive
"ada_main___elabb" (AMEB an acceptable acronym ?).

The GNAT Ada main function has a structure of 

    adainit
    call nothing
    adafinal

I believe that when circumstances require, AMEB will
both contain useful code and be called as part of the
final binary.

Isolating where it is called from is my goal. Prior to
"adainit", from "adainit" or between "adainit" and the
nothing call etc.

AMEB might be a permanent and "legacy" stub, but I doubt
it. I suspect that some features of Ada and GNAT will
populate this function with useful code and call it when
necessary.

Trying to discover the circumstances.

Thanks :-)

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: GNAT internals question

[sk]

Hi, 

Please ignore the statement of my previous post :

-- The pragmas are to remove all external references
-- and dependencies on the GNAT runtime.

I am mixing up my examples, sorry.

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: GNAT internals question

[David C. Hoos]

Hi,

I don't believe ada_main___elabb will ever be called because the
basic structure of the Ada_Main packages is constrolled by the binder,
and the generated code (purposely, I believe) doesn't need any
elaboration code.  If there were any elaboration code generated, it
would need to be called _before_ adainit, given the rule that elaboration
of a package must be done before any of the package's subprograms
is called.

The elaboration code for all programmer-generated code is called by
adainit, so anything that the programmer can do to affect what is in the
Ada_Main package is confined to the elaboration procedures called by
adainit.

The only initialization of data items in the Ada_Main package is done
by means of literals -- i.e., no subprogram is called to do any of the
initialization -- hence, the initialization is accomplished by the
generation
of an initialized data section within the object file.

Am I making this clear?

----- Original Message -----
From: "sk" <noname@myob.com>
To: <comp.lang.ada@ada.eu.org>
Sent: Wednesday, June 26, 2002 4:15 PM
Subject: Re: GNAT internals question


> Hi,
>
> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com>
> > ... not a single instance of ada_main___elabs.
>
> Sorry, I mis-remembered, it is "ada_main___elabb"
> I am refering to.
>
> So far my experience is also that it is not called
> but that doesn't mean that it never is used.
>
> It is difficult for me to describe what I am asking,
> but ...
>
> procedure Nothing is
> begin
>     null;
> end Nothing;
>
> The pragmas are to remove all external references
> and dependencies on the GNAT runtime.
>
> Linux shell commands :
>
>     gnatmake -c -v nothing
>     gnatbind -v nothing
>     gcc -v -c -S b~nothing.adb
>
> producing "b~nothing.s" which contains the elusive
> "ada_main___elabb" (AMEB an acceptable acronym ?).
>
> The GNAT Ada main function has a structure of
>
>     adainit
>     call nothing
>     adafinal
>
> I believe that when circumstances require, AMEB will
> both contain useful code and be called as part of the
> final binary.
>
> Isolating where it is called from is my goal. Prior to
> "adainit", from "adainit" or between "adainit" and the
> nothing call etc.
>
> AMEB might be a permanent and "legacy" stub, but I doubt
> it. I suspect that some features of Ada and GNAT will
> populate this function with useful code and call it when
> necessary.
>
> Trying to discover the circumstances.
>
> Thanks :-)
>
> --
> -------------------------------------
> -- Merge vertically for real address
> -------------------------------------
> s n p @ t . o
>  k i e k c c m
> -------------------------------------
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: GNAT internals question

[sk]

Hi,

"David C. Hoos" <david.c.hoos.sr@ada95.com>
> Am I making this clear?

I think you are saying that "ada_main___elabb" is a stub 
which is never called and that I do not need to worry 
about it ?

My unease arises since the AMEB issue is out of user-domain 
control and vaguely fits into the virtual "environment task"
domain (a very very sketchy comprehension of the LRM), that 
this is implementation defined and therefore under some 
circumstances GNAT might use it. 

The "environment task", as established by the link process 
and the gnat-run-time-library, is far greater than the Ada 
main which has the structure

    adainit
    call my-code
    adafinal

with AMEB floating around somewhere.

Perhaps the AMEB is called by some of the "implementation
defined" "environment task" and run-time libraries prior
to invoking the Ada main ?

If this is all irrelevent, as you suggest, the question
then becomes one of why does gnatbind create AMEB then ?

As an aside, I am not trying to control AMEB, just to 
account for it and ensure that I do not mistakenly 
ignore it when loading an Ada main outside of a
standard OS context.

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: GNAT internals question

[David C. Hoos, Sr.]

The binder does not generate the "AMEB" -- the compiler generates it
as a result of compiling the Ada_Main package of which the _source_code_
was generated by the binder.

Further, consider that the function Ada_Main.main is exported as the
C main function which is called by the C runtime start-up code.

The C runtime startup code knows nothing about Ada, so wouldn't call
the "AMEB," and you can see in the source code of the Ada_Main.main
function everything that is done, showing that nowhere is the "AMEB"
called.

----- Original Message ----- 
From: "sk" <noname@myob.com>
To: <comp.lang.ada@ada.eu.org>
Sent: June 26, 2002 5:28 PM
Subject: Re: GNAT internals question


> Hi,
> 
> "David C. Hoos" <david.c.hoos.sr@ada95.com>
> > Am I making this clear?
> 
> I think you are saying that "ada_main___elabb" is a stub 
> which is never called and that I do not need to worry 
> about it ?
> 
> My unease arises since the AMEB issue is out of user-domain 
> control and vaguely fits into the virtual "environment task"
> domain (a very very sketchy comprehension of the LRM), that 
> this is implementation defined and therefore under some 
> circumstances GNAT might use it. 
> 
> The "environment task", as established by the link process 
> and the gnat-run-time-library, is far greater than the Ada 
> main which has the structure
> 
>     adainit
>     call my-code
>     adafinal
> 
> with AMEB floating around somewhere.
> 
> Perhaps the AMEB is called by some of the "implementation
> defined" "environment task" and run-time libraries prior
> to invoking the Ada main ?
> 
> If this is all irrelevent, as you suggest, the question
> then becomes one of why does gnatbind create AMEB then ?
> 
> As an aside, I am not trying to control AMEB, just to 
> account for it and ensure that I do not mistakenly 
> ignore it when loading an Ada main outside of a
> standard OS context.
> 
> -- 
> -------------------------------------
> -- Merge vertically for real address
> -------------------------------------
> s n p @ t . o
>  k i e k c c m
> -------------------------------------
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

Re: GNAT internals question

[sk]

Hi,

Think I got it :-)

The Ada backend for gcc processes all Ada source the same 
way regardless of whether it is the main or not. In doing
so, a <ada-package-name>___elabb is created for each source 
and all are collectively called from adainit as necessary ?

The resulting AMEB is a side-effect of this treating all 
the source the same way.

Just to see, I produced a "C" binder file and AMEB
disappears which certainly lifted concerns I had about
ignoring it.

Thanks.

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------