Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uwvax!rang From: rang@cs.wisc.edu (Anton Rang) Newsgroups: comp.software-eng Subject: Re: Linkers (was: Re: Coding standards) Message-ID: Date: 7 Dec 89 01:16:43 GMT References: <9185@hoptoad.uucp> <21107@mimsy.umd.edu> Sender: news@spool.cs.wisc.edu Organization: UW-Madison CS department Lines: 52 In-reply-to: cml@tove.umd.edu's message of 5 Dec 89 15:10:11 GMT In article <21107@mimsy.umd.edu> cml@tove.umd.edu (Christopher Lott) writes: >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 No linker should link in unused modules from an object library. However, there is a bit of a tradeoff involved with object files. Many compilers/assemblers resolve references to symbols within the object file at compile time, so that linking is faster. If this is done, the linker can no longer arbitrarily "munge" an object file. >Well! I think this is the transitive-closure problem in a linker, >quite difficult to solve in a straightforward link process. It's not that difficult, as long as references are always resolved at link time (and never at compile time--or at least, if they are resolved at compile time, relocation information is still kept around). The THINK Pascal compiler on the Macintosh works this way: the compiler resolves references at compile time, but when the final build is done the linker removes all procedures which are unused. The VMS compilers mostly create a single object module per source file (not keeping around relocation info). The FORTRAN compiler, however, generates one module per routine (within one object file) which allows the linker to remove unused code. >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. Any system using the BSD UNIX object file format (or similar ones) has to do this; the information needed to move code within a module is not available. >I agree about the previous poster's assesment of "brain damaged" but >perhaps a better description would be "efficient in time, not space." Well...sort of. Hopefully, references within a module will be resolved at compile time instead of link time, which will speed up links. It would still be nice if the object file format included full relocation information, which could be skipped for a fast link, or used for a "small" link. Just my thoughts.... Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+