stluka@neptune.software.org (Fred Stluka) (05/13/91)
VAX Ada or VMS Linker gurus, Is there a way to build an executable image which contains the code for *part* of an Ada package? If I "with" an Ada package, but only call one of its routines, is there any way to avoid having the code for all the routines in the package (and everything they reference) linked into the executable? Please mail; I will summarize, --Fred -- Fred Stluka Internet: stluka@software.org Software Productivity Consortium UUNET: ...!uunet!software!stluka 2214 Rock Hill Rd, Herndon VA 22070 USA
PHALL@ESOC.BITNET (05/14/91)
you don't really say what the exact problem is, however if the problem is that the image size is very large then check the linker map to see how many modules are being linked. if this value is approx 96 it is likley that the linker has stopped performing demand zero compression. the linker option ISD_MAX specifies the maximum number of image sections allowed in an image. The default is approz 96. If the total number of image sections reaches or exceeds this value, demand zero compression stops.
stluka@software.org (Fred Stluka) (05/15/91)
In article <91134.084320PHALL@ESOC.BITNET> PHALL@ESOC.BITNET writes: > you don't really say what the exact problem is, however if the problem > is that the image size is very large ... Yes, the problem is that the image size is huge (7500 blocks), wasting space on disk and time at image activation. I suspect that a major contributing factor is that lots of stuff which is in packages I reference but which I don't ever use is being included in the image. I suspect that the linker always links in an entire object module, regardless of how much is needed to resolve all references. Thus an Ada package containing many routines, or a C file containing many functions, is always completely included in the image, even when many of the routines are never called. Once these rouitnes are included, then other routines which they reference (but which I also never call from my code) must also be included, and so on. Therefore, my question to the net was how to prevent these routines from being linked into the image. I am still interested in an answer to that question, but other tips like the one below are also appreciated. > ... then check the linker map to see > how many modules are being linked. if this value is approx 96 it is likley > that the linker has stopped performing demand zero compression. > the linker option ISD_MAX specifies the maximum number of image sections > allowed in an image. The default is approz 96. If the total number of > image sections reaches or exceeds this value, demand zero compression stops. What is demand zero compression? Are you saying that pages which are entirely zero-filled are stored that way on disk in the image instead of being generated dynamically during a page fault, if the image has more than 96 or so sections? --Fred -- Fred Stluka Internet: stluka@software.org Software Productivity Consortium UUNET: ...!uunet!software!stluka 2214 Rock Hill Rd, Herndon VA 22070 USA
stluka@software.org (Fred Stluka) (05/15/91)
In article <91134.084320PHALL@ESOC.BITNET> PHALL@ESOC.BITNET writes: > you don't really say what the exact problem is, however if the problem > is that the image size is very large then check the linker map to see > how many modules are being linked. if this value is approx 96 it is likley ^^^^^^^ > that the linker has stopped performing demand zero compression. > the linker option ISD_MAX specifies the maximum number of image sections ^^^^^^^^^^^^^^ > allowed in an image. The default is approz 96. If the total number of > image sections reaches or exceeds this value, demand zero compression stops. ^^^^^^^^^^^^^^ Which is the relevant number: "image sections" or modules"? From the "Image Synopsis" of my link map: Number of files: 960 Number of modules: 1039 Number of program sections: 156 Number of image sections: 72 --Fred -- Fred Stluka Internet: stluka@software.org Software Productivity Consortium UUNET: ...!uunet!software!stluka 2214 Rock Hill Rd, Herndon VA 22070 USA
PHALL@ESOC.BITNET (05/16/91)
Check the number of image sections in the image synopsis. If this value is approx 96, it could be that the linker has stopped performing demand zero compression. Demand zero compression is the extracting of contiguous, uninialized writable pages from an image section and placing these pages into a newly created demand zero section. A demand zero image section contains uninitialized, writeable pages which do not occupy physical memory in the image file on disk, but which when accessed during program execution are allocated memory and initialized to zero by VMS.
osman@hwee.UUCP (Osman) (05/22/91)
Maybe I've missed the point but have you considered compiling some of the modules into a shareable image (or using them as a shareable image). This has the advantage that if you use them in several sets of programs you still only need one file. Sorry if I've missed the point. Cabbage.
stluka@software.org (Fred Stluka) (05/22/91)
In article <965@hwee.UUCP> osman@hwee (Osman) writes: > Maybe I've missed the point but have you considered compiling some of the > modules into a shareable image (or using them as a shareable image). This has > the advantage that if you use them in several sets of programs you still only > need one file. Doesn't help (I think). I am only building one program. It "with"s a large Ada package containing hundreds of routines (Ada bindings to a non-Ada collection of routines). I only call a couple of the routines, but the entire package, and therefore all of the non-Ada routines also, get linked into the executable image. Any way to avoid this large image size, short of breaking up the Ada bindings package into multiple packages? Would subunits help? I think the problem would go away if I could convert the single Ada bindings package into an object module library, or shareable image, with one object per routine. Then I could get the linker to selectively link in individual Ada bindings routines. I'd rather not have to modify the source too much to do this though. --Fred -- Fred Stluka Internet: stluka@software.org Software Productivity Consortium UUNET: ...!uunet!software!stluka 2214 Rock Hill Rd, Herndon VA 22070 USA
orville@weyrich.UUCP (Orville R. Weyrich) (05/23/91)
In article <1991May22.133537.419@software.org> stluka@software.org (Fred Stluka) writes: >I am only building one program. It "with"s a large Ada >package containing hundreds of routines (Ada bindings to >a non-Ada collection of routines). I only call a couple >of the routines, but the entire package, and therefore >all of the non-Ada routines also, get linked into the >executable image. > >Any way to avoid this large image size, short of breaking >up the Ada bindings package into multiple packages? Would >subunits help? This may not help your situation much, but the problem is with the dumb linker that you seem to have in your environment. Some Ada systems are able to figure out which entry-points are never used and to not include them in the run-time image. (The professional version of Meridian Ada and/or Janus Ada come to mind, but you'd best check with the vendors for reliable information). The Turbo Pascal compiler also does this (proof of concept, for whatever that is worth). -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************