32-bit SPARC: Procedure Linkage Table
For 32-bit SPARC dynamic objects, the procedure linkage table resides in private data. The runtime linker determines the absolute addresses of the destinations and modifies the procedure linkage table's memory image accordingly.
The first four procedure linkage table entries are reserved. The original contents
of these entries are unspecified, despite the example that is shown in Table 15-14. Each entry
in the table occupies 3 words (12 bytes), and the last table entry is followed by a
nop
instruction.
A relocation table is associated with the procedure linkage table. The
DT_JMP_REL
entry in the _DYNAMIC
array
gives the location of the first relocation entry. The relocation table has one
entry, in the same sequence, for each non-reserved procedure linkage table entry.
The relocation type of each of these entries is R_SPARC_JMP_SLOT
.
The relocation offset specifies the address of the first byte of the associated
procedure linkage table entry. The symbol table index refers to the appropriate
symbol.
To illustrate procedure linkage tables, Table 15-14 shows four entries. Two of the four are
initial reserved entries. The third entry is a call to name101
.
The fourth entry is a call to name102
. The example assumes that
the entry for name102
is the table's last entry. A
nop
instruction follows this last entry. The left column
shows the instructions from the object file before dynamic linking. The right column
illustrates a possible instruction sequence that the runtime linker might use to fix
the procedure linkage table entries.
Table 15-14 32-bit SPARC: Procedure Linkage Table Example
Object File | Memory Segment |
---|---|
.PLT0: unimp unimp unimp .PLT1: unimp unimp unimp |
.PLT0: save %sp, -64, %sp call runtime_linker nop .PLT1: .word identification unimp unimp |
.PLT101: sethi (.-.PLT0), %g1 ba,a .PLT0 nop .PLT102: sethi (.-.PLT0), %g1 ba,a .PLT0 nop nop |
.PLT101: nop ba,a name101 nop .PLT102: sethi (.-.PLT0), %g1 sethi %hi(name102), %g1 jmpl %g1+%lo(name102), %g0 nop |
The following steps describe how the runtime linker and program jointly resolve the symbolic references through the procedure linkage table. The steps that are described are for explanation only. The precise execution-time behavior of the runtime linker is not specified.
-
When the memory image of the program is initially created, the runtime linker changes the initial procedure linkage table entries. These entries are modified so that control can be transferred to one of the runtime linker's own routines. The runtime linker also stores a word of identification information in the second entry. When the runtime linker receives control, this word is examined to identify the caller.
-
All other procedure linkage table entries initially transfer to the first entry. Thus, the runtime linker gains control at the first execution of a table entry. For example, the program calls
name101
, which transfers control to the label.PLT101
. -
The
sethi
instruction computes the distance between the current and the initial procedure linkage table entries,.PLT101
and.PLT0
, respectively. This value occupies the most significant 22 bits of the%g1
register. -
Next, the
ba,a
instruction jumps to.PLT0
, establishing a stack frame, and calls the runtime linker. -
With the identification value, the runtime linker gets its data structures for the object, including the relocation table.
-
By shifting the
%g1
value and dividing by the size of the procedure linkage table entries, the runtime linker calculates the index of the relocation entry forname101
. Relocation entry101
has typeR_SPARC_JMP_SLOT
. This relocation offset specifies the address of.PLT101
, and its symbol table index refers toname101
. Thus, the runtime linker gets the symbol's real value, unwinds the stack, modifies the procedure linkage table entry, and transfers control to the desired destination.
The runtime linker does not have to create the instruction sequences under the memory segment column. If the runtime linkers does, some points deserve more explanation.
-
To make the code re-entrant, the procedure linkage table's instructions are changed in a particular sequence. If the runtime linker is fixing a function's procedure linkage table entry and a signal arrives, the signal handling code must be able to call the original function with predictable and correct results.
-
The runtime linker changes three words to convert an entry. The runtime linker can update only a single word atomically with regard to instruction execution. Therefore, re-entrancy is achieved by updating each word in reverse order. If a re-entrant function call occurs just prior to the last patch, the runtime linker gains control a second time. Although both invocations of the runtime linker modify the same procedure linkage table entry, their changes do not interfere with each other.
-
The first
sethi
instruction of a procedure linkage table entry can fill the delay slot of the previous entry'sjmp1
instruction. Although thesethi
changes the value of the%g1
register, the previous contents can be safely discarded. -
After conversion, the last procedure linkage table entry,
.PLT102
, needs a delay instruction for itsjmp1
. The required, trailingnop
fills this delay slot.
Note:
The different instruction sequences that are shown for.PLT101
, and .PLT102
demonstrate how
the update can be optimized for the associated destination.
The LD_BIND_NOW
environment variable changes dynamic
linking behavior. If its value is non-null, the runtime linker processes
R_SPARC_JMP_SLOT
relocation entries before transferring
control to the program.