181 lines
6.6 KiB
HTML
181 lines
6.6 KiB
HTML
<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>
|