eld Manual
Table Of Contents
- eld Manual
- Legal Notices
- Contents
- What’s New in This Manual
- Manual Information
- New and Changed Information
- About This Manual
- Notation Conventions
- 1 Introduction to eld
- 2 eld Input and Output
- 3 Binding of References
- Overview
- Presetting Loadfiles
- To Preset or Not to Preset, and Creation of the LIC
- Handling Unresolved References
- Using User Libraries
- Creating Import Libraries
- Ignoring Optional Libraries
- Merging Symbols Found in Input Linkfiles
- Accepting Multiply-Defined Symbols
- Using the -cross_dll_cleanup option
- Specifying Which Symbols to Export, and Creating the Export Digest
- Public Libraries and DLLs
- The Public Library Registry
- 4 Other eld Processing
- Adjusting Loadfiles: The -alf Option
- Additional rules about -alf
- The -set and -change Options
- eld Functionality for 64-Bit
- Checking the C++ Language Dialect
- Renaming Symbols
- Creating Linker-Defined Symbols
- Updating Or Stripping DWARF Symbol Table Information
- Modifying the Data Sections that Contain Stack Unwinding Information
- Creating the MCB
- Processing of Floating Point Versions and Data Models
- Specification of the Main Entry Point
- Specifying Runtime Search Path Information for DLLs
- Merging Source RTDUs
- 5 Summary of Linker Options
- 6 Output Listings and Error Handling
- A TNS/E Native Object Files
- Glossary
- Index
Binding of References
eld Manual—527255-009
3-2
Overview
The functions are related because the linker can use symbol resolution to handle
relocation, by assigning a symbol to the base address of each part of the program then
treating the relocatable addresses as references to the base address symbols.
In the case of the HP NonStop operating system compilers; in TNS/R the addresses
started at zero and incremented for each section, in TNS/E all section addresses start
at zero, they don’t really contain addresses but rather contain section offsets.
eld is concerned with cases where the compiler or assembler does not know the
ultimate contents that the object file should contain for symbolic references. Such
cases are listed in the relocation tables that the compiler or assembler creates in
linkfiles. When -r is specified, the linker creates new linkfiles with the same kinds of
relocation tables.
This section considers how the linker creates a loadfile.
In order to fill in the proper values for symbolic references, the linker matches up
symbols across linkfiles, determines runtime addresses for the symbols defined in this
loadfile, and searches other DLLs to resolve references to symbols not defined within
the current object file. The loadfile that is built by the linker tells rld what needs
further examination when the loadfile is brought into virtual memory. The addresses
chosen by the linker are called the preferred addresses for this loadfile. A program is
always loaded at its preferred addresses, but that is not necessarily true for a DLL.
Here are two examples of references:
•
A data item that is a pointer, initialized with the address of another data item. The
compiler or assembler doesn’t know the final address to put in, so it creates a
relocation table entry for this data item. The linker may fill in a value, but in any
case it propagates the same type of relocation table entry to the loadfile for rld to
use.
•
An instruction that refers to some data item. This is different from the case above
because only the linker can modify executable code, not rld. The compiler or
assembler may generate code that looks up the address of the symbol in a data
location whose address is calculated by adding a 22-bit offset to the GP register,
and it creates a relocation table entry accordingly. The linker allocates that data
location as part of the .got section and updates the code so that it contains the
right
22-bit GP-relative offset to reach the corresponding .got section entry. The linker
may also fill in a value in the .got section entry, but in any case it puts information
into the object file so that rld knows how to fill in or update the .got section entry
at load time.
There are various relocation types which tell the linker how to modify a given location
in code or data after it knows the address that need to be represented there. We often
say that the linker “fills in the address of the symbol at the relocation site”, but that isn’t
precisely correct. Depending on the relocation type, it may the actual address of the
symbol, or it may be something else, such as the GP-relative offset of the .got entry
that contains the address of the symbol, and so on.










