Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!ptsfa!ihnp4!laidbak!daveb From: daveb@laidbak.UUCP (Dave Burton) Newsgroups: comp.lang.c Subject: Re: MSC Linking and Libraries Message-ID: <1259@laidbak.UUCP> Date: Sun, 22-Nov-87 16:30:38 EST Article-I.D.: laidbak.1259 Posted: Sun Nov 22 16:30:38 1987 Date-Received: Wed, 25-Nov-87 06:32:54 EST References: <3195@rosevax.Rosemount.COM> Reply-To: daveb@laidbak.UUCP (Dave Burton) Organization: is pretty bad/My method of Lines: 85 Keywords: MSC In article <3195@rosevax.Rosemount.COM> richw@rosevax.Rosemount.COM (Rich Wagenknecht) writes: >1) Does the MSC linker link an entire library to an object file >or does it extract only the functions actually used by the >object code? >2) Why is the executable size of program so much larger >than the object file size? The De Smet compiler I've used seems to >produce much smaller executables than MSC. >3) If the MSC linker does link in an entire library are there >programs which will remove unused library functions. 1)No. No. 2)See below. DeSmet has a better engineered library. 3)Not that I know of/I seriously doubt it. In general: Linkers can only remove objects called "modules" from libraries. A module is simply a source file compiled/assembled into an object file. If the source file contains more than one function, so will the object. A library archiver then places the object module into the library, noting only the existance and location of the module and any external symbols. The linker simply searches the library for these symbols, extracting the MODULE the symbol is defined within. There are pros and cons to the implementation of libraries with multi-function modules: -- Pro -- a) Placing several related functions in the same source file allows them to share variables/buffer space, thus reducing the data space requirements. b) This also means that the related functions can communicate through "private channels" (static global variables) which any potential caller cannot access symbolically. c) Maintenance of these modules is easier than maintaining several source files, especially without the assistance of automated maintenance tools such as SCCS and make. d) Link time will (usually) be improved because the linker may already have the external symbol required (due to retrieving an earlier required module). -- Con -- 1) Executable files contain potentially many dead areas of code, increasing load time, memory usage, and disk space usage. 2) The output of a Static Analysis of these executables will be more complex due to the presence of dead code. 3) Automatic Program Verification becomes more difficult when a section of code is never used: is it because the test suite is incomplete, the program is flawed, or the code is actually dead? Single function modules must be carefully written, however, or references to other external symbols can have a dominoe effect and chain-link the entire library. (A good test of the granularity and quality of a library is the code a program such as: main() { float a=1.2; printf("this is a test\n"); exit(0); } The printf() will want to bring in several different modules to satisfy its complex/diverse conversion requirements. Many compilers define symbols such as "__floatused" to help the linker in determining if certain modules are needed, so the float assignment should trigger this. This is definitely *NOT* the definitive test, but an indicator.) Further, single function modules must now pass information via global symbols (although usually undocumented). As an example of the need to pass information in this manner, consider a set of functions which manage a video screen, and several of the functions can modifiy the state of the screen, such as current page, window, font, attribute, etc. If the library writer is not careful, using just one of these functions can bring in most, if not all, the related functions because of this interaction. Library engineering is the major reason for the reported differences in code size between MSC and DeSmet. While the size of the executable is important, code speed and efficiency is more so. If I had to choose between a 50k executable that would run a given program in 10 seconds vs. a 30k executable that took 25 seconds, I would take the larger. In summary: Although the linker actually does the work and is seen as the culprit of large executables, the library writer is actually at 'fault'. What you are seeing is the engineering decision and implementation quality of the library based upon those decisions. -- --------------------"Well, it looked good when I wrote it"--------------------- Verbal: Dave Burton Net: ...!ihnp4!laidbak!daveb V-MAIL: (312) 505-9100 x325 USSnail: 1901 N. Naper Blvd. #include Naperville, IL 60540