pintos-os.org Git - pintos-anon/blob - specs/sysv-abi-update.html/ch4.reloc.html

   1 <html>
   2 <title>Relocation</title><p>
   3 <h1>Relocation</h1><p>
   4 Relocation is the process of connecting symbolic references
   5 with symbolic definitions.
   6 For example, when a program calls a function, the associated call
   7 instruction must transfer control to the proper destination address
   8 at execution.
   9 Relocatable files must have
  10 ``relocation entries'' which
  11 are necessary because they contain information that
  12 describes how to modify their section contents, thus allowing
  13 executable and shared object files to hold
  14 the right information for a process's program image.
  15 <hr>
  16 <b>Figure 4-21: Relocation Entries</b>
  17 <p>
  18 <pre>
  19 <code>
  20 typedef struct {
  21         Elf32_Addr      r_offset;
  22         Elf32_Word      r_info;
  23 } Elf32_Rel;
  24
  25 typedef struct {
  26         Elf32_Addr      r_offset;
  27         Elf32_Word      r_info;
  28         Elf32_Sword     r_addend;
  29 } Elf32_Rela;
  30
  31 typedef struct {
  32         Elf64_Addr      r_offset;
  33         Elf64_Xword     r_info;
  34 } Elf64_Rel;
  35
  36 typedef struct {
  37         Elf64_Addr      r_offset;
  38         Elf64_Xword     r_info;
  39         Elf64_Sxword    r_addend;
  40 } Elf64_Rela;
  41 </code>
  42 </pre>
  43 <hr>
  44 <DL COMPACT>
  45 <p><dt><code>r_offset</code><dd>
  46 This member gives the location at which to apply the
  47 relocation action.
  48 For a relocatable file,
  49 the value is the byte offset from the beginning of the section
  50 to the storage unit affected by the relocation.
  51 For an executable file or a shared object,
  52 the value is the virtual address
  53 of the storage unit affected by the relocation.
  54 <p><dt><code>r_info</code><dd>
  55 This member gives both the symbol table index with respect to which
  56 the relocation must be made, and the type of relocation to apply.
  57 For example, a call instruction's relocation entry
  58 would hold the symbol table index of the function being called.
  59 If the index is <code>STN_UNDEF</code>,
  60 the undefined symbol index,
  61 the relocation uses 0 as the ``symbol value''.
  62 Relocation types are processor-specific;
  63 descriptions of their behavior appear in the processor
  64 supplement.
  65 When the text below refers to a relocation entry's
  66 relocation type or symbol table index, it means the result of applying
  67 <code>ELF32_R_TYPE</code> (or <code>ELF64_R_TYPE</code>) or <code>ELF32_R_SYM</code> (or <code>ELF64_R_SYM</code>),
  68 respectively, to the entry's <code>r_info</code> member.
  69 <hr>
  70 <PRE>
  71         #define ELF32_R_SYM(i)  ((i)&gt;&gt;8)
  72         #define ELF32_R_TYPE(i)   ((unsigned char)(i))
  73         #define ELF32_R_INFO(s,t) (((s)&lt;&lt;8)+(unsigned char)(t))
  74
  75         #define ELF64_R_SYM(i)    ((i)&gt;&gt;32)
  76         #define ELF64_R_TYPE(i)   ((i)&amp;0xffffffffL)
  77         #define ELF64_R_INFO(s,t) (((s)&lt;&lt;32)+((t)&amp;0xffffffffL))
  78 </PRE>
  79 <hr>
  80 <p><dt><code>r_addend</code><dd>
  81 This member specifies a constant addend used to
  82 compute the value to be stored into the relocatable field.
  83 </dl>
  84 <p>
  85 As specified previously, only
  86 <code>Elf32_Rela</code> and <code>Elf64_Rela</code>
  87 entries contain an explicit addend.
  88 Entries of type <code>Elf32_Rel</code> and <code>Elf64_Rel</code>
  89 store an implicit addend in the location to be modified.
  90 Depending on the processor architecture, one form or the other
  91 might be necessary or more convenient.
  92 Consequently, an implementation for a particular machine
  93 may use one form exclusively or either form depending on context.
  94 <p>
  95 A relocation section references two other sections:
  96 a symbol table and a section to modify.
  97 The section header's <code>sh_info</code> and <code>sh_link</code>
  98 members, described in
  99 <a href=ch4.sheader.html>``Sections''</a>
 100 above, specify these relationships.
 101 Relocation entries for different object files have
 102 slightly different interpretations for the
 103 <code>r_offset</code> member.
 104 <p>
 105 <ul>
 106 <p><li>
 107 In relocatable files, <code>r_offset</code>
 108 holds a section offset.
 109 The relocation section itself describes how to
 110 modify another section in the file; relocation offsets
 111 designate a storage unit within the second section.
 112 <p><li>
 113 In executable and shared object files,
 114 <code>r_offset</code> holds a virtual address.
 115 To make these files' relocation entries more useful
 116 for the dynamic linker, the section offset (file interpretation)
 117 gives way to a virtual address (memory interpretation).
 118 </ul>
 119 Although the interpretation of <code>r_offset</code>
 120 changes for different object files to
 121 allow efficient access by the relevant programs,
 122 the relocation types' meanings stay the same.
 123 <p>
 124 <a name="relocation_composition"></a>
 125 The typical application of an ELF relocation is to determine the
 126 referenced symbol value, extract the addend (either from the
 127 field to be relocated or from the addend field contained in
 128 the relocation record, as appropriate for the type of relocation
 129 record), apply the expression implied by the relocation type
 130 to the symbol and addend, extract the desired part of the expression
 131 result, and place it in the field to be relocated.
 132 <p>
 133 If multiple <i>consecutive</i> relocation records are applied
 134 to the same relocation location (<code>r_offset</code>),
 135 they are <i>composed</i> instead
 136 of being applied independently, as described above.
 137 By <i>consecutive</i>, we mean that the relocation records are
 138 contiguous within a single relocation section.  By <i>composed</i>,
 139 we mean that the standard application described above is modified
 140 as follows:
 141 <ul>
 142 <li>
 143 In all but the last relocation operation of a composed sequence,
 144 the result of the relocation expression is retained, rather
 145 than having part extracted and placed in the relocated field.
 146 The result is retained at full pointer precision of the
 147 applicable ABI processor supplement.
 148 <p><li>
 149 In all but the first relocation operation of a composed sequence,
 150 the addend used is the retained result of the previous relocation
 151 operation, rather than that implied by the relocation type.
 152 </ul>
 153 <p>
 154 Note that a consequence of the above rules is that the location specified
 155 by a relocation type is relevant for the
 156 first element of a composed sequence (and then only for relocation
 157 records that do not contain an explicit addend field) and for the
 158 last element, where the location determines where the relocated value
 159 will be placed.  For all other relocation operands in a composed
 160 sequence, the location specified is ignored.
 161 <p>
 162 An ABI processor supplement may specify individual relocation types
 163 that always stop a composition sequence, or always start a new one.
 164 <a name="relocation_types"></a>
 165 <h2>Relocation Types (Processor-Specific)</h2>
 166 <hr>
 167 <img src=warning.gif alt="NOTE:">
 168 This section requires processor-specific information.  The ABI
 169 supplement for the desired processor describes the details.
 170 <hr>
 171 <a href=ch4.symtab.html><img src=previous.gif alt="Previous"></a>
 172 <a href=contents.html><img src=contents.gif alt="Contents"></a>
 173 <a href=ch5.intro.html><img src=next.gif alt="Next"></a>
 174 <hr>
 175 <i>
 176 <small>
 177 &#169; 1997, 1998, 1999, 2000, 2001 The Santa Cruz Operation, Inc.  All rights reserved.
 178 </small>
 179 </i>
 180 </html>