Re: How do linkers work?

"Dave Wilson" <dwilson@ttl.ie> wrote:
> However, much to my dismay, programs that only use Fred() from the
> library also need to define the functions that Bill() needs __even
> though this code is never executed!__.
>
> Forgive me if I'm displaying a certain ignorance about current linker
> technology, but I thought linkers could figure out certain things like
> which functions will never get called and leave them out.


They usually can. This is often less a function of the linker
technology than of the object module format. Nearly all linker resolve
individual bject modules within a library, although some incremental
linkers (e.g. THINK C on the Macintosh) assume that all library
functions are be linked "in" to make the process faster)


The real issue is: what is the smallest linkable object that can be
represented in the OMF?


Some OMFs (e.g. XCOFF) have an explicit representation of a CSECT
which is the smallest linkable object. Typically a compiler would
generate one CSECT per function, and either place each global variable
in its own CSECT or lump them together (although for languages like
C++ with runtime initializations this can have the effect of hauling
in a lot of support code for variables that are never referenced)


Other OMFs (notably ELF) typically treat the entire object file as the
smallest linkable entity. (Well, really in ELF it is the section but
by convention many compilers place all code from a source file in a
single ..text section)


Anyway, in your case it's probably that the compiler has placed the
functions Fred() and Bill() into the same CSECT/section/whatever, and
so the linker can't separate them.


Some linkers attempt to re-separate the functions by e.g. looking at
the symbol table entries and seeing where each function starts, but
this is heuristic and prone to error, as a compiler or assembler may
have already resolved branches or calls within the CSECT and the
linker would need to disassemble the entire CSECT and find them. Of
course the compiler can guarantee that that never happens, but then
you might try to link code from another compiler and that would fail,
etc.


Hope this is helpful.
--
John McEnerney (johnmce@texas.net)

Return to the comp.compilers page.
Search the comp.compilers archives again.