Re: Rational Apex Ada Linker

["Samuel T. Harris" <u61783@gsde.hso.link.com>]

Kirk J Horne wrote:
> 
> The Ada Rational Apex (2.0.8.D) linker appears to include all
> subprograms from imported subsystens into an executable, even if the
> subprograms aren't referenced by the Ada process being built. This
> causes even small Ada processes to become too large and has become an
> obstacle on the SGI where the "GOT overflow" link error occurs.
> 
> (1) Are any other Rational users having the same problem?
> (2) Is there a work around?
> (3) Does Rational have a "smart" Ada linker?
> 
> Thanks,
> Kirk Horne
> khorne@rsa.hisd.harris.com

Being an old Rational hack and a Apex user since it was in Beta,
I find this surprising. While I could not find supporting evidence
to the claim as it is worded above, I did discover that the issue
is more complicated.

I did some contrived tests to see what is going on.
I defined a package in a view of a subsystem.
Then I defined some procedures in a view of another subsystem.
I import the first view into the second.
Each main procedure (in the second view) simple uses text_io.put_line
to print "hello". One procedure withs the package and one does not.
They do have a slight increase in code size (must be simple package
overhead). 

As I added null procedures to the to the package, I again get
slight increases in the execution size. However, as I add actual
code (which cannot be optimized away) I did NOT get an increase
in size in the procedure which makes no calls, and DID get an
increase in size in the procedure which does make calls.
Note that as I add procedures to the body only of the package
and are not visible outside of the package, the main procedure
making no calls does not change in size.

These increases are not affected by combinations of context switch
values for OPTIMIZATION_OBJECTIVE, OPTIMIZATION_LEVEL, and
PROFILING.

I also get slight increases in size when I add global variables
to the package spec or body, but not when I simply add local
variables to the package procedures (that is, the main procedure
which does not make calls).

Both main procedures increase in size identically as I add code
to the body of the package itself.

So, what we have here is elaboration code. Though I'm not sure
what would be actually done to "elaborate" the spec of a procedure,
not having implemented the code generator for any Ada compiler,
something is being done for each visible procedure. Global package
variables also incur overhead whether limited to the body or not.
Of course, package elaboration code is always included. However,
the binder/linker in Apex does appear to correctly eliminate the
bodies of uncalled procedures. Though I did not specifically
test functions (I can only spend so much time on such things)
I would expect similar results.

BTW, I did these tests with Apex 2.0.8D on SGI equipment under
IRIX 5.3. FYI, Apex using the operating systems linker for the
actual link. This caused some problems in Apex 1.4 on Sun/Solbournes
which we used to use.


-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"