Procedure Linkage Table (Processor-Specific)

The global offset table converts position-independent address calculations to absolute locations. Similarly the procedure linkage table converts position-independent function calls to absolute locations. The link-editor cannot resolve execution transfers such as function calls between different dynamic objects. So, the link-editor arranges to have the program transfer control to entries in the procedure linkage table. The runtime linker thus redirects the entries without compromising the position-independence and shareability of the program's text. Executable files and shared object files have separate procedure linkage tables.

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 13-13. Each entry in the table occupies 3 words (12 bytes), and the last table entry is followed by a nop instruction.

To illustrate procedure linkage tables, Table 13-13 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 13-13 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 for name101. Relocation entry 101 has type R_SPARC_JMP_SLOT. This relocation offset specifies the address of .PLT101, and its symbol table index refers to name101. 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's jmp1 instruction. Although the sethi 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 its jmp1. The required, trailing nop 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.

64-bit SPARC: Procedure Linkage Table

For 64–bit SPARC dynamic objects, the procedure linkage table resides in private data. The runtime linker determines the absolute addresses of the destination 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 13-14. Each of the first 32,768 entries in the table occupies 8 words (32 bytes), and must be aligned on a 32–byte boundary. The table as a whole must be aligned on a 256–byte boundary. If more than 32,768 entries are required, the remaining entries consist of 6 words (24 bytes) and 1 pointer (8 bytes). The instructions are collected together in blocks of 160 entries followed by 160 pointers. The last group of entries and pointers can contain less than 160 items. No padding is required.

Note - The numbers 32,768 and 160 are based on the limits of branch and load displacements respectively with the second rounded down to make the divisions between code and data fall on 256–byte boundaries so as to improve cache performance.

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. For the first 32,767 slots, the relocation offset specifies the address of the first byte of the associated procedure linkage table entry, the addend field is zero. The symbol table index refers to the appropriate symbol. For slots 32,768 and beyond, the relocation offset specifies the address of the first byte of the associated pointer. The addend field is the unrelocated value -(.PLTN + 4). The symbol table index refers to the appropriate symbol.

To illustrate procedure linkage tables, Table 13-14 shows several entries. The first three show initial reserved entries. The following three show examples of the initial 32,768 entries together with possible resolved forms that might apply if the target address was +/- 2 Gbytes of the entry, within the lower 4 Gbytes of the address space, or anywhere respectively. The final two show examples of later entries, which consist of instruction and pointer pairs. The left column shows the instructions from the object file before dynamic linking. The right column demonstrates a possible instruction sequence that the runtime linker might use to fix the procedure linkage table entries.

Table 13-14 64-bit SPARC: Procedure Linkage Table Example

Object File	Memory Segment
.PLT0: unimp unimp unimp unimp unimp unimp unimp unimp .PLT1: unimp unimp unimp unimp unimp unimp unimp unimp .PLT2: unimp	.PLT0: save %sp, -176, %sp sethi %hh(runtime_linker_0), %l0 sethi %lm(runtime_linker_0), %l1 or %l0, %hm(runtime_linker_0), %l0 sllx %l0, 32, %l0 or %l0, %l1, %l0 jmpl %l0+%lo(runtime_linker_0), %o1 mov %g1, %o0 .PLT1: save %sp, -176, %sp sethi %hh(runtime_linker_1), %l0 sethi %lm(runtime_linker_1), %l1 or %l0, %hm(runtime_linker_1), %l0 sllx %l0, 32, %l0 or %l0, %l1, %l0 jmpl %l0+%lo(runtime_linker_0), %o1 mov %g1, %o0 .PLT2: .xword identification
.PLT101: sethi (.-.PLT0), %g1 ba,a %xcc, .PLT1 nop nop nop; nop nop; nop .PLT102: sethi (.-.PLT0), %g1 ba,a %xcc, .PLT1 nop nop nop; nop nop; nop .PLT103: sethi (.-.PLT0), %g1 ba,a %xcc, .PLT1 nop nop nop nop nop nop	.PLT101: nop mov %o7, %g1 call name101 mov %g1, %o7 nop; nop nop; nop .PLT102: nop sethi %hi(name102), %g1 jmpl %g1+%lo(name102), %g0 nop nop; nop nop; nop .PLT103: nop sethi %hh(name103), %g1 sethi %lm(name103), %g5 or %hm(name103), %g1 sllx %g1, 32, %g1 or %g1, %g5, %g5 jmpl %g5+%lo(name103), %g0 nop
.PLT32768: mov %o7, %g5 call .+8 nop ldx [%o7+.PLTP32768 - (.PLT32768+4)], %g1 jmpl %o7+%g1, %g1 mov %g5, %o7 ... .PLT32927: mov %o7, %g5 call .+8 nop ldx [%o7+.PLTP32927 - (.PLT32927+4)], %g1 jmpl %o7+%g1, %g1 mov %g5, %o7	.PLT32768: <unchanged> <unchanged> <unchanged> <unchanged> <unchanged> <unchanged> ... .PLT32927: <unchanged> <unchanged> <unchanged> <unchanged> <unchanged> <unchanged>
.PLTP32768 .xword .PLT0 - (.PLT32768+4) ... .PLTP32927 .xword .PLT0 - (.PLT32927+4)	.PLTP32768 .xword name32768 - (.PLT32768+4) ... .PLTP32927 .xword name32927 - (.PLT32927+4)

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 is transfer to the runtime linker's own routines. The runtime linker also stores an extended word of identification information in the third 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 or second entry. These entries establish a stack frame and call the runtime linker.
With the identification value, the runtime linker gets its data structures for the object, including the relocation table.
The runtime linker computes the index of the relocation entry for the table slot.
With the index information, 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 linker 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 can change up to eight 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 first overwriting the nop instructions with their replacement instructions, and then patching the ba,a, and the sethi if using a 64–bit store. 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.
If the initial sethi instruction is changed, the instruction can only be replaced by a nop.

Changing the pointer as done for the second form of entry is done using a single atomic 64–bit store.

Note - The different instruction sequences that are shown for .PLT101, .PLT102, and .PLT103 demonstrate how the update can be optimized for the associated destination.

32-bit x86: Procedure Linkage Table

For 32–bit x86 dynamic objects, the procedure linkage table resides in shared text but uses addresses in the private global offset table. The runtime linker determines the absolute addresses of the destinations and modifies the global offset table's memory image accordingly. The runtime linker thus redirects the entries without compromising the position-independence and shareability of the program's text. Executable files and shared object files have separate procedure linkage tables.

Table 13-15 32-bit x86: Absolute Procedure Linkage Table Example

.PLT0:
    pushl   got_plus_4
    jmp     *got_plus_8
    nop;    nop
    nop;    nop
.PLT1:
    jmp     *name1_in_GOT
    pushl   $offset
    jmp     .PLT0@PC
.PLT2:
    jmp     *name2_in_GOT
    pushl   $offset
    jmp     .PLT0@PC

Table 13-16 32-bit x86: Position-Independent Procedure Linkage Table Example

.PLT0:
    pushl   4(%ebx)
    jmp     *8(%ebx)
    nop;    nop
    nop;    nop
.PLT1:
    jmp     *name1@GOT(%ebx)
    pushl   $offset
    jmp     .PLT0@PC
.PLT2:
    jmp     *name2@GOT(%ebx)
    pushl   $offset
    jmp     .PLT0@PC

Note - As the preceding examples show, the procedure linkage table instructions use different operand addressing modes for absolute code and for position-independent code. Nonetheless, their interfaces to the runtime linker are the same.

The following steps describe how the runtime linker and program cooperate to resolve the symbolic references through the procedure linkage table and the global offset table.

When the memory image of the program is initially created, the runtime linker sets the second and third entries in the global offset table to special values. The following steps explain these values.
If the procedure linkage table is position-independent, the address of the global offset table must be in %ebx. Each shared object file in the process image has its own procedure linkage table, and control transfers to a procedure linkage table entry only from within the same object file. So, the calling function must set the global offset table base register before calling the procedure linkage table entry.
For example, the program calls name1, which transfers control to the label .PLT1.
The first instruction jumps to the address in the global offset table entry for name1. Initially, the global offset table holds the address of the following pushl instruction, not the real address of name1.
The program pushes a relocation offset (offset) on the stack. The relocation offset is a 32–bit, nonnegative byte offset into the relocation table. The designated relocation entry has the type R_386_JMP_SLOT, and its offset specifies the global offset table entry used in the previous jmp instruction. The relocation entry also contains a symbol table index, which the runtime linker uses to get the referenced symbol, name1.
After pushing the relocation offset, the program jumps to .PLT0, the first entry in the procedure linkage table. The pushl instruction pushes the value of the second global offset table entry (got_plus_4 or 4(%ebx)) on the stack, giving the runtime linker one word of identifying information. The program then jumps to the address in the third global offset table entry (got_plus_8 or 8(%ebx)), to jump to the runtime linker.
The runtime linker unwinds the stack, checks the designated relocation entry, gets the symbol's value, stores the actual address of name1 in its global offset entry table, and jumps to the destination.
Subsequent executions of the procedure linkage table entry transfer directly to name1, without calling the runtime linker again. The jmp instruction at .PLT1 jumps to name1 instead of falling through to the pushl instruction.

The LD_BIND_NOW environment variable changes dynamic linking behavior. If its value is non-null, the runtime linker processes R_386_JMP_SLOT relocation entries before transferring control to the program.

x64: Procedure Linkage Table

For x64 dynamic objects, the procedure linkage table resides in shared text but uses addresses in the private global offset table. The runtime linker determines the absolute addresses of the destinations and modifies the global offset table's memory image accordingly. The runtime linker thus redirects the entries without compromising the position-independence and shareability of the program's text. Executable files and shared object files have separate procedure linkage tables.

Table 13-17 x64: Procedure Linkage Table Example

.PLT0:
    pushq   GOT+8(%rip)                         # GOT[1]
    jmp     *GOT+16(%rip)                       # GOT[2]
    nop;    nop
    nop;    nop
.PLT1:
    jmp     *name1@GOTPCREL(%rip)               # 16 bytes from .PLT0
    pushq   $index1
    jmp     .PLT0
.PLT2:
    jmp     *name2@GOTPCREL(%rip)               # 16 bytes from .PLT1
    pushl   $index2
    jmp     .PLT0

The following steps describe how the runtime linker and program cooperate to resolve the symbolic references through the procedure linkage table and the global offset table.

When the memory image of the program is initially created, the runtime linker sets the second and third entries in the global offset table to special values. The following steps explain these values.
Each shared object file in the process image has its own procedure linkage table, and control transfers to a procedure linkage table entry only from within the same object file.
For example, the program calls name1, which transfers control to the label .PLT1.
The first instruction jumps to the address in the global offset table entry for name1. Initially, the global offset table holds the address of the following pushq instruction, not the real address of name1.
The program pushes a relocation index (index1) on the stack. The relocation offset is a 32–bit, nonnegative index into the relocation table. The relocation table is identified by the DT_JUMPREL dynamic section entry. The designated relocation entry has the type R_AMD64_JMP_SLOT, and its offset specifies the global offset table entry used in the previous jmp instruction. The relocation entry also contains a symbol table index, which the runtime linker uses to get the referenced symbol, name1.
After pushing the relocation index, the program jumps to .PLT0, the first entry in the procedure linkage table. The pushq instruction pushes the value of the second global offset table entry (GOT+8) on the stack, giving the runtime linker one word of identifying information. The program then jumps to the address in the third global offset table entry (GOT+16), to jump to the runtime linker.
The runtime linker unwinds the stack, checks the designated relocation entry, gets the symbol's value, stores the actual address of name1 in its global offset entry table, and jumps to the destination.
Subsequent executions of the procedure linkage table entry transfer directly to name1, without calling the runtime linker again. The jmp instruction at .PLT1 jumps to name1 instead of falling through to the pushq instruction.

The LD_BIND_NOW environment variable changes dynamic linking behavior. If its value is non-null, the runtime linker processes R_AMD64_JMP_SLOT relocation entries before transferring control to the program.

Skip Navigation Links
Exit Print View
	Oracle Solaris 11.1 Linkers and Libraries Guide Oracle Solaris 11.1 Information Library