Re: Newbie questions (where's the FAQ)

[Ian Lance Taylor <iant at google dot com>]

boggler <fklotz@cisco.com> writes:

> 5.  I am especially interested in incremental linking, both as described in
> some messages on the forum (existing executable plus new/replacement .o
> files, to create a new executable quickly), AND something else that I think
> of as incremental linking, but which may need a different name to avoid
> confusion - namely, pre-linking together significant chunks of object code,
> so that the final link only deals with a few large chunks, with minimal
> cross-connections, rather than 50,000+ separate object files with hundreds
> of thousands (if not millions) of references to resolve.  I would be
> interested in hearing from people who are working on, or have a special
> interest in, either of these concepts.

Cary addressed your other questions.

On this one, I think it's an interesting idea, although I'm not sure how
much it will speed things up in practice.  Right now a relocatable link
(with the -r option) does not eliminate any of the relocations.

In practice, ld -r could eliminate all PC-relative relocations against
symbols which can not be overridden.  That would be a clear speedup.
There is no reason not to do that for cases where it is possible.  The
trick is knowing when it is permitted.  By default, it is normally not
permitted.  The output of ld -r might be linked into a shared library.
When linking into a shared library, by default relocations against
external symbols must remain, because the dynamic linker might need to
override them at runtime.  So the only way to do this with ld -r is to
add some option specifying that the output will not be linked into a
shared library.

Converting non-PC-relative relocations is never a clear speedup.  The
linker still has to compute the final symbol values.  Once you do that,
getting the value to use during a relocation computation is fast.

Ian