Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ames!dftsrv!mimsy!tove.umd.edu!cml From: cml@tove.umd.edu (Christopher Lott) Newsgroups: comp.software-eng Subject: Re: Linkers (was: Re: Coding standards) Message-ID: <21107@mimsy.umd.edu> Date: 5 Dec 89 15:10:11 GMT References: <9185@hoptoad.uucp> Sender: news@mimsy.umd.edu Reply-To: cml@tove.umd.edu (Christopher Lott) Organization: The University of Maryland Dept of Computer Science Lines: 66 in <9185@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: | WHAT? What year is this? I don't think I've ever used a linker that | didn't eliminate unused routines. Any such linker would be seriously | brain damaged. | -- | Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Well! I think this is the transitive-closure problem in a linker, quite difficult to solve in a straightforward link process. I'm thinking of the unix linker, which (I am told) makes exactly 1 pass through the object files it is told to read, collecting everything that it finds, and finally resolving unknown externals from libraries. Deciding whether or not to link in a module requires the linker to know if it is ever going to be used. Since the linker hasn't seen all the code yet, it can't know, so it adds it in. In an ideal world, the linker should keep track of ALL references to externals, and run through its data 1 more time to kick out all externals that were not referenced. This can be verified easily on any machine. sort-of-c-code: -----snip------- main() { printf("hello, world\n"); } void never_called_func(i, j, k) int i, j, k; { i = 1; printf("i = %d\n", i); j = 2; printf("j = %d\n", j); k = 3; printf("k = %d\n", k); < repeat above lines a hundred times or so > } -----snip------- (You really need > 100 filler lines for them to take up noticeable space.) Compile this into an object and examine the executable size. Then remove function "never_called_func", recompile, and reexamine. Then if you really want to be convinced, compile never_called_func in a library and link the simple program with that library. I know from personal experience using Microsoft C v5.1 on a PC that that particular linker includes ALL code in all modules that are ".o" files and includes ONLY the modules needed from libraries. I agree about the previous poster's assesment of "brain damaged" but perhaps a better description would be "efficient in time, not space." ....time out for testing.....ok. On tove, a vax something runing 4.3Tahoe, the standard linker is dumb. (uh, "efficient in time, not space" :-) ....another time-out....ok. Ditto for the GNU linker. Anyone know if the GNU project has plans to build a better linker?? chris... -- cml@tove.umd.edu Computer Science Dept, U. Maryland at College Park 4122 A.V.W. 301-454-8711