Re: Linkers - making executables smaller

The Moderator wrote:
| [Other than adding support for shared libraries, linkers seem to be
| getting dumber as the years pass. I have seen references to globally
| optimizing linkers. I think decwrl did one, and the MINIX linker
| (which was really the assembler) may have as well. -John]


Templates in C++ have finally forced this issue. While it is possible
to implement templates using traditional linkers, it's not possible to
do *good* implementations.


When you compile multiple object files with templates, you can end up
with duplicate instantiations of the same template in multiple object
files. Some linkers (AIX) have had the minimal modification needed to
handle this: They issue a warning, pick one implementation to link
against, and leave the others in the code, unused. This gives you
really big executables (though presumably the dead code never pages
in.) The HPUX linker, on the other hand, is clever enough to omit the
extra implementation entirely. (Apparently the HPUX linker will get
more clever in subsequent releases. It's already unsupported to link
in any way except using the aCC command line - but under the covers,
aCC does invoke ld. In future versions, it will apparently do all the
work itself.)


Global optimization is another thing that's driving linkers to do
more. Again on HPUX, if you ask for higher levels of optimization,
you'll find that you get .o files - but they apparently aren't real
object files in the traditional sense. Rather, they are some kind of
compiler il. The linker recognizes them, of course, and invokes an
optimizer on them at link time. (Hence, you can do things like
cross-compilation-unit inlining.) Does make "link" times rather long,
unfortunately.


I know there are other compilers on other systems that can do cross-
module optimization. Presumably they can do similar things.


Many linkers (AIX's is one) can do type-checking at link time without
the name-mangling that C++ traditionally uses, though how widely this
is actually used, I don't know.


Now, you can argue that it's the optimizer, not the linker, that's
getting smarter. But that simply indicates how limited our
traditional way of dividing things up into phases has become. Yes, in
the old days, the compiler produced object files - basically, machine
code plus relocation information - and the linker resolved the
relocation information. If that's how you define a linker, then
you've defined away any possibility of a significantly more functional
"linker".


"Classic Unix" linkers were probably about as minimalist as any you
can find after the early 60's. They cause a great deal of pain for
developers of languages with more sophisticated type and execution
models than C and FORTRAN, for which they were designed - hence name
mangling and "munch" (for static initializer support) in C++
implementations. I think the trend has (finally) reversed.


-- Jerry
--

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