From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac9fffa36bbbedcb X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: Rational Apex Ada Linker Date: 1996/08/30 Message-ID: <3227A271.794B@gsde.hso.link.com>#1/1 X-Deja-AN: 177674560 references: <32249623.7C09@harris.com> content-type: text/plain; charset=us-ascii organization: Hughes Training Inc. - Houston Operations mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 3.0 (X11; I; IRIX 5.3 IP19) Date: 1996-08-30T00:00:00+00:00 List-Id: 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!"