Re: Newbie questions (where's the FAQ)

[boggler <fklotz at cisco dot com>]

Lance,

Thanks for the explanation.  I am using the linker to build for embedded
systems where we do not use dynamic libraries, so for me a sensible default
for -r relocatable builds would be to resolve all the references we can, and
discard those relocations, as we will definitely not need them again.  But I
do see from your explanation that this might not be widely useful to others,
just to me.

If I were adding an option for this, it would be a single command-line
option for the entire build, not a per-symbol or per-file option addressing
different symbols/relocations differently.

Thanks,
Frank


Ian Lance Taylor-3 wrote:
> 
> 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
> 
> 

-- 
View this message in context: http://www.nabble.com/Newbie-questions-%28where%27s-the-FAQ%29-tp22251297p22280526.html
Sent from the Sourceware - binutils list mailing list archive at Nabble.com.