SYSTEM V APPLICATION BINARY INTERFACE M32R Architecture Processor Supplement Draft 0.00 1. INTRODUCTION The M32R Architecture and the System V ABI The System V Application Binary Interface, or ABI, defines a system interface for compiled application programs. Its purpose is to establish a standard binary interface for application programs on systems that implement the interfaces defined in the System V Interface Definition, Edition 4. This document is a supplement to the generic System V ABI, and it contains information specific to System V implementations built on the M32R processor architecture. Together, these two specifications, the generic System V ABI and the M32R Architecture System V ABI Supplement (hereafter referred to as the M32R ABI), constitute a complete System V Application Binary Interface specification for systems that implement the processor architecture of the M32R microprocessors. Note that this M32R ABI applies to any system built with the M32R processor chips. How to Use the M32R Architecture ABI Supplement This document is a supplement to the generic System V ABI and contains information referenced in the generic specification that may differ when System V is implemented on different processors. Therefore, the generic ABI is the prime reference document, and this supplement is provided to fill gaps in that specification. As with the System V ABI, this specification references other publicly- available reference documents, especially the Renesas M32R User's Manual. All the information referenced by this supplement should be considered part of this specification, and just as binding as the requirements and data explicitly included here. Evolution of the ABI Specification The System V Application Binary Interface will evolve over time to address new technology and market requirements, and will be reissued at intervals of approximately three years. Each new edition of the specification is likely to contain extensions and additions that will increase the potential capabilities of applications that are written to confirm to the ABI. As with the System V Interface Definition, the ABI will implement Level 1 and Level 2 support for its constituent parts. Level 1 support indicates that a portion of the specification will configure to be supported indefinitely, while Level 2 support means that a portion of the specification may be withdrawn or altered after the next edition of the ABI is made available. That is, a portion of the specification moved to Level 2 support in an edition of the ABI specification will remain in effect at least until the following edition of the specification is published. These Level 1 and Level 2 classifications and qualifications apply to this Supplement, as well as to the generic specification. All components of the ABI and of this supplement have Level 1 support unless they are explicitly labelled as Level 2. The following documents may be of interest to the reader of this specification: - M32R User's Manual (Renesas Literature) - System V Interface Definition, Edition 4 2. SOFTWARE INSTALLATION No changes required. 3. LOW-LEVEL SYSTEM INFORMATION Machine Interface Processor Architecture The Renesas M32R User's Manual (Renesas Literature) defines the processor architecture. The architecture is hereafter referred to as the M32R architecture. Programs intended to execute directly on the processor use the instruction set, instruction encodings, and instruction semantics of the architecture. Three points deserve explicit mention. - A program may assume all documented instructions exist. - A program may assume all documented instructions work. - A program may use only the instructions defined by the architecture. In other words, from a program's perspective, the execution environment provides a complete and working implementation of the M32R architecture. This does not imply that the underlying implementation provides all instructions in hardware, only that the instructions perform the specified operations and produce the specified results. The ABI neither places performance constraints on systems nor specifies what instructions must be implementation in hardware. A software emulation of the architecture could conform to the ABI. Some processors might support the M32R architecture as a subset, providing additional instructions or capabilities. Programs that use those capabilities explicitly do not conform to the M32R ABI. Executing those programs on machines without the additional capabilities gives undefined behavior. Data Representation Within this specification, the term halfword refers to a 16-bit object, the term word refers to a 32-bit object, and the term doubleword refers to a 64-bit object. * Fundamental Types Figure 3-1 shows the correspondence between ANSI C's scalar types and the processor's. ----- Figure 3-1: Scalar Types Alignment M32R Type C sizeof (bytes) Architecture ------------------------------------------------------------------------- char 1 1 signed byte signed char 1 1 ------------------------------------------------------------ unsigned char 1 1 unsigned byte ------------------------------------------------------------ short 2 2 signed halfword signed short ------------------------------------------------------------ unsigned short 2 2 unsigned halfword ------------------------------------------------------------ Integral int signed int long 4 4 signed word signed long enum ------------------------------------------------------------ unsigned int 4 4 unsigned word unsigned long ------------------------------------------------------------------------- Pointer any-type * 4 4 unsigned word any-type (*){} ------------------------------------------------------------------------- float 4 4 single-precision(IEEE) Floating-point double 8 4 double-precision(IEEE) long double 8 4 double-precision(IEEE) ----- NOTE: The M32R architecture does not require doubleword alignment for double-precision values. Nevertheless, for data structure compatibility with other Renesas architectures, compilers may provide a method to align double-precision values on doubleword boundaries. * Aggregates and Unions * Bit-Fields Function Calling Sequence Registers and the Stack Frame CPU Registers ------------- Register Name Use (software name) ------------------------------------------------------------ r0 - r3 Used for passing arguments to functions. Additional arguments are passed on the stack (see below). r0,r1 is also used to return the result of function calls. The values of these registers are not preserved across function calls. r4 - r7 Temporary registers for expression evaluation. The values of these registers are not preserved across function calls. r6 is also reserved for use as a temp in the PIC calling sequence (if ever necessary) and may not be used in the function calling sequence or prologue of functions. r7 is also used as the static chain pointer in nested functions (a GNU C extension) and may not be used in the function calling sequence or prologue of functions. r8 - r11 Temporary registers for expression evaluation. The values of these registers are preserved across function calls. r12 Temporary register for expression evaluation. Its value is preserved across function calls. It is also reserved for use as potential "global pointer". r13 (fp) Frame pointer. r14 (lr) Link register. This register contains the return address in function calls. r15 (sp) Stack pointer. Special CPU Registers --------------------- condition bit This is a 1 bit register that contains the result of compare instructions. accumulator This is a 64 bit register that contains the result of multiply/accumulate instructions. 1. The stack grows downwards from high addresses to low addresses. 2. A leaf function need not allocate a stack frame if it doesn't need one. 3. A frame pointer need not be allocated. 4. The stack pointer shall always be aligned to 4 byte boundaries. 5. The register save area shall be aligned to a 4 byte boundary. Stack frames for functions that take a fixed number of arguments look like: Before call After call +---------------------+ +---------------------+ | | | | high | local variables, | | local variables, | mem | reg save area, etc. | | reg save area, etc. | | | | | +---------------------+ +---------------------+ | | | | | arguments on stack | | arguments on stack | | | | | SP,FP->+---------------------+ +---------------------+ | | | register save area | | | +---------------------+ | | | local variables | | | +---------------------+ | | | alloca allocations | | | +---------------------+ | | low | arguments on stack | memory | | SP,FP->+---------------------+ Note that FP points to the same location as SP. Stack frames for functions that take a variable number of arguments look like: Before call After call +---------------------+ +---------------------+ | | | | high | local variables, | | local variables, | mem | reg save area, etc. | | reg save area, etc. | | | | | +---------------------+ +---------------------+ | | | | | arguments on stack | | arguments on stack | | | | | SP,FP->+---------------------+ +---------------------+ | | | save area for | | anonymous parms | | passed in registers | | (the size of this | | area may be zero) | | | +---------------------+ | | | register save area | | | +---------------------+ | | | local variables | | | +---------------------+ | | | alloca allocations | | | +---------------------+ | | low | arguments on stack | memory | | SP,FP->+---------------------+ Argument Passing ---------------- Arguments are passed to a function using first registers and then memory if the argument passing registers are used up. Each register is assigned an argument until all are used. Unused argument registers have undefined values on entry. The following rules must be adhered to. 1. Quantities of size 8 bytes or less are passed in registers if available, then memory. Larger quantities are passed by reference. 2. Arguments passed by reference are passed by making a copy on the stack and then passing a pointer to that copy. 3. If a data type would overflow the register arguments, then it is passed in registers and memory. e.g. A `long long' data type passed in r3 would be passed in r3 and the first 4 bytes of the stack. 4. Arguments passed on the stack begin at `sp' with respect to the caller. 5. Each argument passed on the stack is aligned on a 4 byte boundary. 6. Space for all arguments is rounded up to a multiple of 4 bytes. Function Return Values ---------------------- Integers, floating point values, and aggregates of 8 bytes or less are returned in register r0 (and r1 if necessary). Aggregates larger than 8 bytes are returned by having the caller pass the address of a buffer to hold the value in r0 as an "invisible" first argument. All arguments are then shifted down by one. The address of this buffer is returned in r0. Functions Returning Scalars or No Value Functions Returning Structures or Unions Integral and Pointer Arguments Floating-Point Arguments Structure and Union Arguments Operating System Interface Virtual Address Space * Page Size * Virtual Address Assignments * Managing the Process Stack * Coding Guidelines Processor Execution Modes Execution Interface * Hardware Exception Types * Software Trap Types Process Initialization * Special Registers * Process Stack and Registers Coding Examples The general descriptive text in either (2) or (3) apply here. Function Calls -------------- Absolute Direct Calls: C Assembly extern void function (); function (); bl function Absolute Indirect Calls: C Assembly extern void (*ptr) (); (*ptr)(); ld24 r4,#ptr ld r5,@r4 jl r5 Switch Tables: Absolute code model: C Assembly void foo () { ... switch (j) ld r4,[j] { cmpui r4,#4 case 0: bnc .Ldef ... slli r4,#2 case 2: ld24 r5,#.Ltab ... add r4,r5 case 3: ld r4,@r4 ... jmp r4 default: ... } ... } .section .rodata .Ltab: .word .Lcase0 .word .Ldef .word .Lcase2 .word .Lcase3 Code Model Overview Position-Independent Function Prologue Data Objects Function Calls Branching C Stack Frame Variable Argument List Allocating Stack Space Dynamically While C does not require dynamic stack allocation within a function, this ABI supports them. The stack pointer must be kept aligned to 4 byte boundaries. 4. OBJECT FILES ELF Header Machine Information For file identification e_ident, the M32R architecture requires the following values. ----- Figure 4-1: M32R Identification, e_ident Position Value ---------------------------------- e_ident[BI_CLASS] ELFCLASS32 e_ident[BI_DATA] ELFDATA2MSB ---------------------------------- ----- Processor identification resides in the ELF header's e_machine member and must have the value EM_M32R. The ELF header's e_flags member holds bit flags associated with the file. The M32R architecture defines no flags; so this member contains zero. Sections Special Sections Various sections hold programs and control information. Sections in the list below are used by the system and have the indicated types and attributes. ----- Figure 4-2: Special Sections Name Type Attributes --------------------------------------------------- .got SHT_PROGBITS SHF_ALLOC + SHF_WRITE .plt SHT_PROGBITS SHF_ALLOC + SHF_EXECINSTR --------------------------------------------------- ----- .got This section holds the global offset table. See "Coding Examples" in Chapter 3 and "Global Offset Table" in Chapter 5 for more information. .plt This section holds the procedure linkage table. See "Procedure Linkage Table" in Chapter 5 for more information. Symbol Table Symbol Values If an executable file contains a reference to a function defined in one of its associated shared objects, the symbol table section for that file will contain an entry for that symbol. The st_shndx member of that symbol table entry contains SHN_UDEF. This signals to the dynamic linker that the symbol definition for that function is not contained in the executable file itself. If that symbol has been allocated a procedure linkage table entry in the executable file, and the st_value member for that symbol table entry is non-zero, the value will contain the virtual address of the first instruction of that procedure linkage table entry. Otherwise, the st_value member contains zero. This procedure linkage table entry address is used by the dynamic linker in resolving references to the address of the function. See "Function Addresses" in Chapter 5 for details. Relocation Relocation Types Relocation entries describe how to alter the following instruction and data fields (bit numbers appear in the lower box corners). ----- Figure 4-3: Relocatable Fields +-----------------+ | word16 | |0 15| +-----------------+ +-----------------------------------+ | word32 | |0 31| +-----------------------------------+ +-----------------+-----------------+ | hi16 | | |0 15| 31| +-----------------+-----------------+ +-----------------+-----------------+ | | lo16 | |0 |16 31| +-----------------+-----------------+ +--------+--------------------------+ | | imm24 | |0 |8 31| +--------+--------------------------+ +--------+--------+ | | disp8 | |0 |8 15| +--------+--------+ +-----------------+-----------------+ | | disp16 | |0 |16 31| +-----------------+-----------------+ +--------+--------------------------+ | | disp24 | |0 |8 31| +--------+--------------------------+ ----- word32 This specifies a 32-bit fields occupying 4 bytes with arbitrary byte alignment. These values use the same byte order as other word values in the M32R architecture. +--------+--------+--------+--------+ | 0| 1| 2| 3| | 01 | 02 | 03 | 04 | 0x01020304 |0 | | | 31| +--------+--------+--------+--------+ Calculations below assume the actions are transforming a relocatable file into either an executable or a shared object file. Conceptually, the link editor merges one or more relocatable files to form the output. It first decides how to combine and locate the input files, then updates the symbol values, and finally performs the relocation. Relocations applied to executable or shared object files are similar and accomplish the same result. Descriptions below use the following notation. A This means the added used to compute the value of the relocatable field. B This means the base address at which a shared object has been loaded into memory during execution. Generally, a shared object file is built with a 0 base virtual address, but the execution address will be different. See "Program Header" in the System V ABI for more information about the base address. G This means the offset into the global offset table at which the address of the relocation entry's symbol will reside during execution. See "Coding Examples" in Chapter 3 and "Global Offset Table" in Chapter 5 for more information. GOT This means the address of the global offset table. See "Coding Examples" in Chapter 3 and "Global Offset Table" in Chapter 5 for more information. L This means the place (section offset or address) of the procedure linkage table entry for a symbol. A procedure linkage table entry redirects a function call to the proper destination. The link editor builds the initial procedure linkage table, and the dynamic linker modifies the entries during execution. See "Procedure Linkage Table" in Chapter 5 for more information. P This means the place (section offset or address) of the storage unit being relocated (computed using r_offset). S This means the value of the symbol whose index resides in the relocation entry. A relocation entry's r_offset value designates the offset or virtual address of the first byte of the affected storage unit. The relocation type specifies which bits to change and how to calculate their values. The M32R architecture uses only Elf32_Rel relocation entries, the field to be relocated holds the addend. In all cases, the addend and the computed result use the same byte order. ----- Figure 4-4: Relocation Types Name Value Field Calculation --------------------------------------------------------------------- R_M32R_NONE 0 none none R_M32R_16 1 half16 (S+A)&0xFFFF ------ R_M32R_32 2 word32 S+A ^ R_M32R_24 3 imm24 (S+A)&0xFFFFFF | R_M32R_10_PCREL 4 disp8 ((S+A-P)>>2)&0xFF | R_M32R_18_PCREL 5 disp16 ((S+A-P)>>2)&0xFFFF | R_M32R_26_PCREL 6 disp24 ((S+A-P)>>2)&0xFFFFFF | R_M32R_HI16_ULO 7 imm16 ((S+A)>>16) OLD TYPE R_M32R_HI16_SLO 8 simm16 ((S+A)>>16) | or ((S+A+0x10000)>>16) | R_M32R_LO16 9 imm16 (S+A)&0xFFFF | R_M32R_SDA16 10 simm16 (S+A)&0xFFFF | R_M32R_GNU_VTINHERIT 11 V R_M32R_GNU_VTENTRY 12 ------ R_M32R_16_RELA 33 half16 (S+A)&0xFFFF R_M32R_32_RELA 34 word32 S+A R_M32R_24_RELA 35 imm24 (S+A)&0xFFFFFF R_M32R_10_PCREL_RELA 36 disp8 ((S+A-P)>>2)&0xFF R_M32R_18_PCREL_RELA 37 disp16 ((S+A-P)>>2)&0xFFFF R_M32R_26_PCREL_RELA 38 disp24 ((S+A-P)>>2)&0xFFFFFF R_M32R_HI16_ULO_RELA 39 imm16 ((S+A)>>16) R_M32R_HI16_SLO_RELA 40 simm16 ((S+A)>>16) or ((S+A+0x10000)>>16) R_M32R_LO16_RELA 41 imm16 (S+A)&0xFFFF R_M32R_SDA16_RELA 42 simm16 (S+A)&0xFFFF R_M32R_RELA_GNU_VTINHERIT 43 R_M32R_RELA_GNU_VTENTRY 44 R_M32R_GOT24 48 imm24 G+A-P R_M32R_26_PLTREL 49 disp24 L+A-P R_M32R_COPY 50 none none R_M32R_GLOB_DAT 51 word32 S R_M32R_JMP_SLOT 52 word32 S R_M32R_RELATIVE 53 word32 B+A R_M32R_GOTOFF 54 word32 S+A-GOT R_M32R_GOTPC24 55 word32 GOT+A-P R_M32R_GOT16_HI_ULO 56 imm16 ((G+A-P)>>16) R_M32R_GOT16_HI_SLO 57 imm16 ((G+A-P)>>16) or ((G+A-P+0x10000)>>16) R_M32R_GOT16_LO 58 imm16 (G+A-P)&0xFFFF R_M32R_GOTPC_HI_ULO 59 imm16 (GOT+A-P)>>16 R_M32R_GOTPC_HI_SLO 60 imm16 (GOT+A-P)>>16 or ((GOT+A-P+0x10000)>>16) R_M32R_GOTPC_LO 61 imm16 (GOT+A-P)&0xFFFF --------------------------------------------------------------------- ----- Some relocation types have semantics beyond simple calculation. R_M32R_GOT24 R_M32R_GOT16_HI_ULO R_M32R_GOT16_HI_SLO R_M32R_GOT16_LO This relocation type computes the distance from the base of the global offset table to the symbol's global offset table entry. It additionally instructs the link editor to build a global offset table. ex1) ld24 r12,#label ex2) seth r12,#high(label) or3 r12,r12,#low(label) ex3) seth r12,#shigh(label) add3 r12,r12,#low(label) R_M32R_26_PLTREL This relocation type computes the address of the symbol's procedure linkage table entry and additionally instructs the link editor to build a global offset table. R_M32R_COPY The link editor creates this relocation type for dynamic linking. Its offset member refers to a location in a writable segment. The symbol table index specifies a symbol that should exist both in the current object file and in a shared object. During execution, the dynamic linker copies data associated with the shared object's symbol to the location specified by the offset. R_M32R_GLOB_DAT This relocation type used to set a global offset table entry to the address of the specified symbol. The special relocation type allows one to determine the correspondence between symbols and global offset table entries. R_M32R_JMP_SLOT The link editor creates this relocation type for dynamic linking. Its offset member gives the location of a procedure linkage table entry. The dynamic linker modifies the procedure linkage table to transfer control to the designated symbol's address (See "Procedure Linkage Table" in Chapter 5). R_M32R_RELATIVE The link editor creates this relocation type for dynamic linking. Its offset member gives the location within a shred object that contains a value representing a relative address. The dynamic linker computes the corresponding virtual address by adding the virtual address at which the shared object was loaded to the relative address. Relocation entries for this type must specify 0 for the symbol table index. R_M32R_GOTOFF This relocation type computes the difference between a symbol's value and the address of the global offset table. It additionally instructs the link editor to build the global offset table. R_M32R_GOTPC24 R_M32R_GOTPC_HI_ULO R_M32R_GOTPC_HI_SLO R_M32R_GOTPC_LO This relocation type resembles R_M32R_26_PCREL, except it uses the address of the global offset table in its calculation. The symbol referenced in this relocation normally is _GLOBAL_OFFSET_TABLE_, which additionally instructs the link editor to build a global offset table. ex1) ld24 r12,#_GLOBAL_OFFSET_TABLE_ ex2) seth r12,#high(_GLOBAL_OFFSET_TABLE_) or3 r12,r12,#low(_GLOBAL_OFFSET_TABLE_+4) ex3) seth r12,#shigh(_GLOBAL_OFFSET_TABLE_) add3 r12,r12,#low(_GLOBAL_OFFSET_TABLE_+4) 5. PROGRAM LOADING AND DYNAMIC LINKING Program Loading As the system creates or arguments a process image, it logically copies a file's segment to a virtual memory segment. When -- and if -- the system physically reads the file depends on the program's execution behavior, system load, and so on. A process does not require a physical page unless it references the logical page during execution, and processes commonly leave many pages unreferenced. Therefore, delaying physical reads frequently obviates them, improving system performance. To obtain this efficiently in practice, executable and shared object files must have segment images whose file offsets and virtual addresses are congruent, modulo the page size. Virtual addresses and file offsets for the M32R architecture segments are congruent modulo 4KB (0x1000) or larger powers of 2. Because 4KB is the maximum page size, the files will be suitable for paging regardless of physical page size. ----- Figure 5-1: Executable File File Offset File Virtual Address +-------------------------+ 0 | ELF header | +-------------------------+ | Program header table | +-------------------------+ | Other information | +-------------------------+ 0x1000 | Text segment | 0x8048000 | ... | | 0x2be00 bytes | 0x8073dff +-------------------------+ 0x2ce00 | Data segment | 0x8074e00 | ... | | 0x4e00 bytes | 0x8079bff +-------------------------+ 0x31c00 | Other information | | ... | +-------------------------+ ----- ... Not written yet. Dynamic Linking Dynamic Section Dynamic section entries give information to the dynamic linker. Some of this information is processor-specific, including the interpretation of some entries in the dynamic structure. DT_PLTGOT On the M32R architecture, the entry's d_ptr member gives the address of the first entry in the global offset table. As mentioned below, the first three global offset table entries are reserved, and two are used to hold procedure linkage table information. Global Offset Table Position-independent code cannot, in general, contain absolute virtual addresses. Global offset tables hold absolute addresses in private data, thus making the addresses available without compromising the position- independence and sharability of a program's text. A program references its global offset table using position-independent addressing and extracts absolute values, thus redirecting position-independent references to absolute locations. Initially, the global offset table holds information as required by its relocation entries [see "Relocation" in Chapter 4]. After the system creates memory segments for a loadable object file, the dynamic linker processes the relocation entries, some of which will be type R_M32R_GLOB_DAT referring to the global offset table. The dynamic linker determines the associated symbol values, calculates their absolute addresses, and sets the appropriate memory table entries to the proper values. Although the absolute addresses are unknown when the link editor builds an object file, the dynamic linker knows the addresses of all memory segments and can thus calculate the absolute addresses of the symbols contained therein. If a program requires direct access to the absolute address of a symbol, that symbol will have a global offset table entry. Because the executable file and shared objects have separate global offset tables, a symbol's address may appear in several tables. The dynamic linker processes all the global offset table relocations before giving control to any code in the process image, thus ensuring the absolute addresses are available during execution. The table's entry zero is reserved to hold the address of the dynamic structure, referenced with the symbol _DYNAMIC. This allows a program, such as the dynamic linker, to find its own dynamic structure without having yet processed its relocation entries. This is especially important for the dynamic linker, because it must initialize itself without relying on other programs to relocate its memory image. On the M32R architecture, entries one and two in the global offset table also are reserved. "Procedure Linkage Table" below describes them. The system may choose different memory segment addresses for the same shared object in different programs; it may even choose different library addresses for different executions of the same program. Nonetheless, memory segments do not change addresses once the process image is established. As long as a process exists, its memory segments reside at fixed virtual addresses. A global offset table's format and interpretation are processor-specific. For the M32R architecture, the symbol _GLOBAL_OFFSET_TABLE_ may be used to access the table. ----- Figure 5-5: Global Offset Table extern Elf32_Addr _GLOBAL_OFFSET_TABLE_[]; ----- Function Addresses References to the address of a function from an executable file and the shared objects associated with it might not resolve to the same value. References from within shared objects will normally be resolved by the dynamic linker to the virtual address of the function itself. References from within the executable file to a function defined in a shared object will normally be resolved by the link editor to the address of the procedure linkage table entry for that function within the executable file. To allow comparisons of function addresses to work as expected, if an executable file references a function defined in a shared object, the link editor will place the address of the procedure linkage table entry for that function in its associated symbol table entry. [See "Symbol Values" in Chapter 4]. The dynamic linker treats such symbol table entries specially. If the dynamic linker is searching for a symbol, and encounters a symbol table entry for that symbol in the executable file, it normally follows the rules below. 1. If the st_shndx member of the symbol table entry is not SHN_UNDEF, the dynamic linker has found a definition for the symbol and uses its st_value members as the symbol's address. 2. If the st_shndx member is SHN_UNDEF and the symbol is of type STT_FUNC and the st_value member is not zero, the dynamic linker recognizes this entry as special and uses the st_value member as the symbol's address. 3. Otherwise, the dynamic linker considers the symbol to be undefined within the executable file and continues processing. Some relocations are associated with procedure linkage table entries. These entries are used for direct function calls rather than for references to function addresses. These relocations are not treated in the special way described above because the dynamic linker must not redirect procedure linkage table entries to point to themselves. Procedure Linkage Table Much as the global offset table redirects position-independent address calculations to absolute locations, the procedure linkage table redirects position-independent function calls to absolute locations. The link editor cannot resolve execution transfers (such as function calls) from one executable or shared object to another. Consequently, the link editor arranges to have the program transfer control to entries in the procedure linkage table. On the M32R architecture, procedure linkage tables reside in shared text, but they use addresses in the private global offset table. The dynamic linker determines the destinations' absolute addresses and modifies the global offset table's memory image accordingly. The dynamic linker thus can redirect the entries without compromising the position- independence and sharability of the program's text. Executable files and shared object files have separate procedure linkage tables. ----- Figure 5-6: Absolute Procedure Linkage Table (32-bit version) .PLT0: seth r6,#high(.got+4) or3 r6,r6,#low(.got+4) ld r4,@r6+ ; argument to the linker (id of GOT) ld r6,@r6 ; dynamic linker address jmp r6 .PLT1: seth r6,#shigh(.got+name1_GOT) ld r6,@(low(.got+name1_GOT),r6) jmp r6 ld24 r5,#name1_dynamic_offset ; arg to the linker (reloc offset) bra .PLT0 ... .PLTn: seth r6,#shigh(.got+nameN_GOT) ld r6,@(low(.got+nameN_GOT),r6) jmp r6 ld24 r5,#nameN_dynamic_offset ; arg to the linker (reloc ofsset) bra .PLT0 ... PLT entry max-size is 20byte. ----- ----- Figure 5-7: Position-Independent Procedure Linkage Table (32-bit version) .PLT0: ld r4,@(4,r12) ; argument to the linker (id of GOT) on stack ld r6,@(8,r12) ; dynamic linker address jmp r6 ... .PLTn: ld24 r6,#nameN_GOT add r6,r12 ld r6,@r6 jmp r6 ld24 r5,#nameN_dynamic_offset ; arg to the linker (reloc offset) bra .PLT0 ... PLT entry max-size is 20byte. ----- Following the steps below, the dynamic linker and the program "cooperate" to resolve symbolic references through the procedure linkage table and the global offset table. 1. When first creating the memory image of the program, the dynamic linker sets the second and the third entries in the global offset table to special values. Steps below explain more about these values. 2. If the procedure linkage table is position-independent, the address of the global offset table must reside in R12. 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. Consequently, the calling function is responsible for setting the global offset table base register before calling the procedure linkage table entry. 3. For illustration, assume the program calls name1, which transfers control to the label .PLT1. 4. 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 ld24 instruction, not the real address of name1. 5. Consequently, the program loads a relocation offset (offset) into R4. The relocation offset is a 32-bit, non-negative byte offset into the relocation table. The designated relocation entry will have type R_M32R_JMP_SLOT, and its offset will specify the global offset table entry used in the previous jmp instruction. The relocation entry also contains a symbol table index, thus telling the dynamic linker what symbol is being referenced, name1 in this case. 6. After loading the relocation offset, the program then jumps to .PLT0, the first entry in the procedure linkage table. The ld instruction sets the value of the second global offset table entry (@(4,R12)) to R6, thus giving the dynamic linker one word of identifying information. The program then jumps to the address in the third global offset table entry (@(8,R12)), which transfers control to the dynamic linker. 7. When the dynamic linker receives control, it refers to the arguments passed by the registers R4 and R5, looks at the designated relocation entry, finds the symbol's value, stores the "real" address of name1 in its global offset table entry, and transfers control to the desired destination. 8. Subsequent executions of the procedure linkage table entry will transfer directly to name1, without calling the dynamic linker a second time. That is, the ld24 instruction at .PLT1 will transfer to name1, instead of "falling through" to the next ld24 instruction. The LD_BIND_NOW environment variable can change dynamic linking behavior. If its value is non-null, the dynamic linker evaluates procedure linkage table entries before transferring control to the program. That is, dynamic linker processes relocation entries of type R_M32R_JMP_SLOT during process initialization. Otherwise, the dynamic linker evaluates procedure linkage table entries lazily, delaying symbol resolution and relocation until the first execution of a table entry. NOTE: Lazy binding generally improves overall application performance, because unused symbols do not incur the dynamic linking overhead. Nevertheless, two situations make lazy binding undesirable for some applications. First, the initial reference to a shared object function takes longer than subsequent calls, because the dynamic linker intercepts the call to resolve the symbol. Some applications cannot tolerate this unpredictability. Second, if an error occurs and the dynamic linker cannot resolve the symbol, the dynamic linker will terminate the program. Under lazy binding, this might occur at arbitrary times. Once again, some applications cannot tolerate this unpredictability. By turning off lazy binding, the dynamic linker forces the failure to occur during process initialization, before the application receives control. Program Interpreter There is one valid program interpreter for programs conforming to the M32R ABI: /usr/lib/ld-linux.so.2 6. LIBRARY No changes required. 7. DEVELOPMENT ENVIRONMENT No changes required. 8. EXECUTION ENVIRONMENT No changes required.