--- /dev/null
+<html>
+<title>Relocation</title><p>
+<h1>Relocation</h1><p>
+Relocation is the process of connecting symbolic references
+with symbolic definitions.
+For example, when a program calls a function, the associated call
+instruction must transfer control to the proper destination address
+at execution.
+Relocatable files must have
+``relocation entries'' which
+are necessary because they contain information that
+describes how to modify their section contents, thus allowing
+executable and shared object files to hold
+the right information for a process's program image.
+<hr>
+<b>Figure 4-21: Relocation Entries</b>
+<p>
+<pre>
+<code>
+typedef struct {
+ Elf32_Addr r_offset;
+ Elf32_Word r_info;
+} Elf32_Rel;
+
+typedef struct {
+ Elf32_Addr r_offset;
+ Elf32_Word r_info;
+ Elf32_Sword r_addend;
+} Elf32_Rela;
+
+typedef struct {
+ Elf64_Addr r_offset;
+ Elf64_Xword r_info;
+} Elf64_Rel;
+
+typedef struct {
+ Elf64_Addr r_offset;
+ Elf64_Xword r_info;
+ Elf64_Sxword r_addend;
+} Elf64_Rela;
+</code>
+</pre>
+<hr>
+<DL COMPACT>
+<p><dt><code>r_offset</code><dd>
+This member gives the location at which to apply the
+relocation action.
+For a relocatable file,
+the value is the byte offset from the beginning of the section
+to the storage unit affected by the relocation.
+For an executable file or a shared object,
+the value is the virtual address
+of the storage unit affected by the relocation.
+<p><dt><code>r_info</code><dd>
+This member gives both the symbol table index with respect to which
+the relocation must be made, and the type of relocation to apply.
+For example, a call instruction's relocation entry
+would hold the symbol table index of the function being called.
+If the index is <code>STN_UNDEF</code>,
+the undefined symbol index,
+the relocation uses 0 as the ``symbol value''.
+Relocation types are processor-specific;
+descriptions of their behavior appear in the processor
+supplement.
+When the text below refers to a relocation entry's
+relocation type or symbol table index, it means the result of applying
+<code>ELF32_R_TYPE</code> (or <code>ELF64_R_TYPE</code>) or <code>ELF32_R_SYM</code> (or <code>ELF64_R_SYM</code>),
+respectively, to the entry's <code>r_info</code> member.
+<hr>
+<PRE>
+ #define ELF32_R_SYM(i) ((i)>>8)
+ #define ELF32_R_TYPE(i) ((unsigned char)(i))
+ #define ELF32_R_INFO(s,t) (((s)<<8)+(unsigned char)(t))
+
+ #define ELF64_R_SYM(i) ((i)>>32)
+ #define ELF64_R_TYPE(i) ((i)&0xffffffffL)
+ #define ELF64_R_INFO(s,t) (((s)<<32)+((t)&0xffffffffL))
+</PRE>
+<hr>
+<p><dt><code>r_addend</code><dd>
+This member specifies a constant addend used to
+compute the value to be stored into the relocatable field.
+</dl>
+<p>
+As specified previously, only
+<code>Elf32_Rela</code> and <code>Elf64_Rela</code>
+entries contain an explicit addend.
+Entries of type <code>Elf32_Rel</code> and <code>Elf64_Rel</code>
+store an implicit addend in the location to be modified.
+Depending on the processor architecture, one form or the other
+might be necessary or more convenient.
+Consequently, an implementation for a particular machine
+may use one form exclusively or either form depending on context.
+<p>
+A relocation section references two other sections:
+a symbol table and a section to modify.
+The section header's <code>sh_info</code> and <code>sh_link</code>
+members, described in
+<a href=ch4.sheader.html>``Sections''</a>
+above, specify these relationships.
+Relocation entries for different object files have
+slightly different interpretations for the
+<code>r_offset</code> member.
+<p>
+<ul>
+<p><li>
+In relocatable files, <code>r_offset</code>
+holds a section offset.
+The relocation section itself describes how to
+modify another section in the file; relocation offsets
+designate a storage unit within the second section.
+<p><li>
+In executable and shared object files,
+<code>r_offset</code> holds a virtual address.
+To make these files' relocation entries more useful
+for the dynamic linker, the section offset (file interpretation)
+gives way to a virtual address (memory interpretation).
+</ul>
+Although the interpretation of <code>r_offset</code>
+changes for different object files to
+allow efficient access by the relevant programs,
+the relocation types' meanings stay the same.
+<p>
+<a name="relocation_composition"></a>
+The typical application of an ELF relocation is to determine the
+referenced symbol value, extract the addend (either from the
+field to be relocated or from the addend field contained in
+the relocation record, as appropriate for the type of relocation
+record), apply the expression implied by the relocation type
+to the symbol and addend, extract the desired part of the expression
+result, and place it in the field to be relocated.
+<p>
+If multiple <i>consecutive</i> relocation records are applied
+to the same relocation location (<code>r_offset</code>),
+they are <i>composed</i> instead
+of being applied independently, as described above.
+By <i>consecutive</i>, we mean that the relocation records are
+contiguous within a single relocation section. By <i>composed</i>,
+we mean that the standard application described above is modified
+as follows:
+<ul>
+<li>
+In all but the last relocation operation of a composed sequence,
+the result of the relocation expression is retained, rather
+than having part extracted and placed in the relocated field.
+The result is retained at full pointer precision of the
+applicable ABI processor supplement.
+<p><li>
+In all but the first relocation operation of a composed sequence,
+the addend used is the retained result of the previous relocation
+operation, rather than that implied by the relocation type.
+</ul>
+<p>
+Note that a consequence of the above rules is that the location specified
+by a relocation type is relevant for the
+first element of a composed sequence (and then only for relocation
+records that do not contain an explicit addend field) and for the
+last element, where the location determines where the relocated value
+will be placed. For all other relocation operands in a composed
+sequence, the location specified is ignored.
+<p>
+An ABI processor supplement may specify individual relocation types
+that always stop a composition sequence, or always start a new one.
+<a name="relocation_types"></a>
+<h2>Relocation Types (Processor-Specific)</h2>
+<hr>
+<img src=warning.gif alt="NOTE:">
+This section requires processor-specific information. The ABI
+supplement for the desired processor describes the details.
+<hr>
+<a href=ch4.symtab.html><img src=previous.gif alt="Previous"></a>
+<a href=contents.html><img src=contents.gif alt="Contents"></a>
+<a href=ch5.intro.html><img src=next.gif alt="Next"></a>
+<hr>
+<i>
+<small>
+© 1997, 1998, 1999, 2000, 2001 The Santa Cruz Operation, Inc. All rights reserved.
+</small>
+</i>
+</html>
projects / pintos-anon / blobdiff