|Dead code elimination email@example.com (Steve Boswell) (1991-10-26)|
|re: Dead code elimination firstname.lastname@example.org (Chuck Lins) (1991-10-28)|
|Re: Dead code elimination email@example.com (1991-10-29)|
|Re: Dead code elimination firstname.lastname@example.org (1991-11-01)|
|Re: Dead code elimination email@example.com (1991-11-05)|
|Re: Re: Dead Code Elimination firstname.lastname@example.org (1991-11-10)|
|From:||Chuck Lins <email@example.com>|
|Keywords:||linker, C, Lisp, Fortran|
|Date:||28 Oct 91 09:22:05 U|
In 91-10-106 Steve Boswell <firstname.lastname@example.org> asks about
removal of uncallable routines from a binary.
In the Apple MPW development environment, the Linker is responsible for
this task. The Linker uses information in the object file to find all
procedure calls (even indirect through a register). I don't think it even
builds a graph, just a list of all procedures explicitly referenced. Any
routine in a .o file but not on the list constructed above isn't placed in
the final binary. (I didn't write the linker and have never looked at it's
source, so this is speculation but appears accurate based on experience
with it's results.)
***** soapbox - hit 'n' now *****
Of course as John mentioned, routines like printf cause extra code to be
brought in. Lisp has a similar problem when 'eval' is used. IMHO, this is
poor language/library design (understandable given the age of C and Lisp).
It much better on the compiler (and linker) to have individual routines
doing specific things. Such a design mitigates the aforementioned problem.
Plus, such capabilities as printf should be in the development environment
which could automatically expand it into the sequence of individual
routines. The compiler could then in-line them if necessary, compile
stack frames, etc.
Chuck Lins, Oberon-2 Paladin. email@example.com
[Son of Soapbox: I've seen Fortran compilers that scan the format statements
at compile time and emit external references to just the routines needed,
and I suppose there is something to be said for the PL/I approach to
formatted I/O in which the parameters of the format entries can be variable,
but not their types. But it does seem to me a little backward to say that
Lisp's eval() is bad because it makes life hard for the linker. -John]
Return to the
Search the comp.compilers archives again.