eld Manual

Binding of References
eld Manual—527255-009
3-4
Overview
The linker does not necessarily know the proper load time values to use for addresses,
because things can change between link time and load time for reasons such as these:
•
The DLL currently being built, or the other DLLs to which it refers, will not
necessarily be loaded at the same (preferred) addresses as those assumed by the
linker.
•
The other DLLs to which the current loadfile refers may not be the same DLLs
used at runtime, because they might be updated in the interim. Thus, a given DLL
may no longer provide the same set of symbols, or it may provide the same
symbols but at different addresses. This updating of DLLs may also change which
DLLs are indirectly found.
•
Although the same DLLs may be in the same places at load time as at link time,
different ones may be used because rld looks for them with different path lists.
Also, the rules that are used for binding references at load time are not rules that could
be completely implemented by the linker, even if things didn’t change as described
above. For instance, it is possible for a reference from a globalized or semi-globalized
DLL to be resolved in the main program at load time, but the linker does not see the
main program when it is building that DLL. The rules are such that, if things don’t
change as described above, and if the linker is creating a main program or a localized
DLL, then it will search the same DLLs, and in the same order, as rld.
Some symbols are exported by the loadfile that contains them, and some are not. Only
the exported symbols are visible to other loadfiles.
The linker fills in all references to symbols that are defined in the same loadfile, using
the address of the symbol within this same loadfile.
In some cases what the linker fills in may need to be modified by rld, but the linker
still guarantees to fill in all these references that were within the same file. rld may
be able to decide that this much of what the linker did was correct, and therefore avoid
the need to recalculate those references at load time. Or, rld may recalculate the
references, because it wasn’t sure that what the linker did was correct, and in such
cases it can still be advantageous if the linker was correct.
The linker also may fill in other references, to symbols not defined within this same
loadfile. In particular, the linker may do this for symbols that are not globalized
symbols, and that process is called presetting. References to globalized symbols are
not filled in, and do not generate errors or warnings. When the linker fills in references
to undefined symbols rld may again be able to decide that what the linker did was
correct, and therefore avoid additional work at load time.
There is a concept that goes under various names, such as “delayed binding”, “lazy
evaluation”, etc. This refers to the situation where there can be procedure call
references that are purposely not resolved at link time, or even at load time. Instead,
the first time the procedure is called, the rld runtime support resolves its address. HP
NonStop systems do not support this capability.