in .o files; these are the old relocs......
Reloc Number Reloc Name Meaning 1 R_386_32 simply deposit the absolute memory of "symbol" into a dword 2 R_386_PC32 determine the distance from this memory location to the "symbol", then read this dword and add it to said distance deposit the result back into this dword; this is a relative jump or call
These four were introduced with dynamic libraries; they are found only in .o files which are going to be part of a library (pic code):
Reloc Number Reloc Name Meaning 3 R_386_GOT32 this reloc is going to persist through the link stage; the linker should change this reloc into a R_386_GLOB_DATA in the library file a R_386_GOTPC determine the distance from here to the _GLOBAL_OFFSET_TABLE and deposit the difference as a dword into this location 9 R_386_GOTOFF determine the distance from the .got to the "symbol" (local symbol) store that distance as a dword at this location; create an entry in the .got table; change this reloc into a R_386_RELATIVE and point it at the .got entry 4 R_386_PLT32 create a new entry in the .plt table and .got; determine the distance from here to the .plt entry, and store that distance as a dword at this location; rename the reloc to R_386_JMP_SLOT (still the same "symbol") and point it at the .got entry
Executable files that are built "static" have no relocs in them. They run standalone.
In executable files which are intended to run with shared libraries......
Reloc Number Reloc Name Meaning 7 R_386_JMP_SLOT at load time, deposit &.plt[0] into this dword at dynamic link time, deposit the address of the "symbol" subroutine into this dword 5 R_386_COPY read a string of bytes from the "symbol" address and deposit a copy into this dword; the "symbol" object contains the length; this is used to copy initialized data from a library to the main app data space
In dynamic library files...
Reloc Number Reloc Name Meaning 7 R_386_JMP_SLOT resolved as above 6 R_386_GLOB_DATA at load time, deposit the address of "symbol" into this dword; the "symbol" is in the main app; this is, in a sense, the complement of R_386_COPY above* 8 R_386_RELATIVE at dynamic-link time: read the dword at this location; add to it the run-time start address of this module; deposit the result back into the dword
Note that R_386_32 relocs can appear in libraries as well. These must be executed carefully!
*The reason I phrased it this way is the following. Suppose you have a global data object defined in a dynamic library. The library will have the binary version of the object in its .data space. When the application is built, the linker puts a R_386_COPY reloc in there to copy the data down to the application's .bss space. In turn, the library never references the original global object; it references the copy that is in the application space, through a corresponding R_386_GLOB_DATA. Wierd, huh? After loading, the original data is never used; only the copy.
To make the whole dynamic linking operation happen, the linker introduces several "synthetic" constructs into the target when you build an app or a library:
.got Global Offset Table This is a small section of data memory where run-time fixups are made; there is only one of these per-app or per-library
_GLOBAL_OFFSET_TABLE_ A pointer to the .got
.plt Procedure Lookup Table This is a small section of code memory which helps the run-time resolution work properly
The compiler can signal to the assembler that it wants to trigger one of the above constructs by:
implicit func i386 syntax ARM syntax .got pointer var&GOT(%ebs) var(GOT) .got data var&GOTOFF(%ebx) var(GOTOFF) _GLOBAL_OFFSET_TABLE_ same same .plt func&PLT func(PLT)
Note that the C/C++ programmer does not allocate this memory; it is created by, and used by the linker.
To make the job of the linker a bit easier, the relocs are clustered together in the app-file or the library-file.
.rel.bss section contains all the R_386_COPY type relocs .rel.plt section contains all the R_386_JMP_SLOT type relocs .rel.got section contains all the R_386_GLOB_DATA type relocs .rel.data section contains all the R_386_32 and R_386_RELATIVE type relocs