provided code
This commit is contained in:
LabTS
1184
specs/sysv-abi-update.html/ch4.eheader.html
Normal file
1184
specs/sysv-abi-update.html/ch4.eheader.html
Normal file
File diff suppressed because it is too large
Load Diff
252
specs/sysv-abi-update.html/ch4.intro.html
Normal file
252
specs/sysv-abi-update.html/ch4.intro.html
Normal file
@@ -0,0 +1,252 @@
|
||||
<html>
|
||||
<title>Chapter 4: Object Files</title>
|
||||
<h1>Introduction</h1>
|
||||
This chapter describes the
|
||||
object file format, called ELF (Executable and Linking Format).
|
||||
There are three main types of object files.
|
||||
<ul>
|
||||
<p><li>
|
||||
A <i>relocatable file</i>
|
||||
holds code and data suitable for linking
|
||||
with other object files to create an executable
|
||||
or a shared object file.
|
||||
<p><li>
|
||||
An <i>executable file</i>
|
||||
holds a program suitable for execution;
|
||||
the file specifies how
|
||||
<code>exec</code>(BA_OS)
|
||||
creates a program's process image.
|
||||
<p><li>
|
||||
A
|
||||
<i>shared object file</i>
|
||||
holds code and data suitable for linking
|
||||
in two contexts.
|
||||
First, the link editor [see <code>ld</code>(BA_OS)]
|
||||
processes the shared object file with other relocatable
|
||||
and shared object files to create another object file.
|
||||
Second, the dynamic linker combines it with an executable file and other
|
||||
shared objects to create a process image.
|
||||
</ul>
|
||||
<p>
|
||||
Created by the assembler and link editor, object files are binary
|
||||
representations of programs intended to be executed directly on
|
||||
a processor. Programs that require other abstract machines, such
|
||||
as shell scripts, are excluded.
|
||||
</p>
|
||||
<p>
|
||||
After the introductory material, this chapter focuses on the file
|
||||
format and how it pertains to building programs. Chapter 5 also
|
||||
describes parts of the object file, concentrating on the information
|
||||
necessary to execute a program.
|
||||
</p>
|
||||
<a name=file_format></a>
|
||||
<h2>File Format</h2><p>
|
||||
Object files participate in program linking (building a program)
|
||||
and program execution (running a program). For convenience and
|
||||
efficiency, the object file format provides parallel views of a file's
|
||||
contents, reflecting the differing needs of those activities.
|
||||
Figure 4-1 shows an object file's organization.
|
||||
<hr>
|
||||
<b>Figure 4-1: Object File Format</b>
|
||||
<p>
|
||||
<table>
|
||||
<tr><td width="250">
|
||||
<table border=1 cellspacing=0>
|
||||
<caption align=bottom><b>Linking View</b></caption>
|
||||
<tr><td align=center>ELF Header</td></tr>
|
||||
<tr><td align=center>Program header table<br><i>optional</i></td></tr>
|
||||
<tr><td align=center>Section 1</td></tr>
|
||||
<tr><td align=center>...</td></tr>
|
||||
<tr><td align=center>Section n</td></tr>
|
||||
<tr><td align=center>...</td></tr>
|
||||
<tr><td align=center>Section header table<br><i>required</i></td></tr>
|
||||
</table>
|
||||
</td>
|
||||
<td>
|
||||
<table border=1 cellspacing=0>
|
||||
<caption align=bottom><b>Execution View</b></caption>
|
||||
<tr><td align=center>ELF Header</td></tr>
|
||||
<tr><td align=center>Program header table<br><i>required</i></td></tr>
|
||||
<tr><td align=center>Segment 1<br></td></tr>
|
||||
<tr><td align=center>Segment 2<br></td></tr>
|
||||
<tr><td align=center>Segment 3<br></td></tr>
|
||||
<tr><td align=center>...</td></tr>
|
||||
<tr><td align=center>Section header table<br><i>optional</i></td></tr>
|
||||
</table>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
<p>
|
||||
An <i>ELF header</i> resides at the beginning and
|
||||
holds a ``road map''
|
||||
describing the file's organization. <i>Sections</i> hold the bulk
|
||||
of object file information for the linking view: instructions,
|
||||
data, symbol table, relocation information, and so on.
|
||||
Descriptions of special sections appear later in the chapter.
|
||||
Chapter 5 discusses <i>segments</i> and the program execution
|
||||
view of the file.
|
||||
</p>
|
||||
<p>
|
||||
A <i>program header table</i> tells the system how to create a process image.
|
||||
Files used to build a process image (execute a program)
|
||||
must have a program header table; relocatable files do not need one.
|
||||
A <i>section header table</i>
|
||||
contains information describing the file's sections.
|
||||
Every section has an entry in the table; each entry
|
||||
gives information such as the section name, the
|
||||
section size, and so on.
|
||||
Files used during linking must have a section header table;
|
||||
other object files may or may not have one.
|
||||
<p><hr>
|
||||
<img src=warning.gif alt="NOTE:">
|
||||
Although the figure shows the program header table
|
||||
immediately after the ELF header, and the section header table
|
||||
following the sections, actual files may differ.
|
||||
Moreover, sections and segments have no specified order.
|
||||
Only the ELF header has a fixed position in the file.
|
||||
<hr><p>
|
||||
<a name=data_representation></a>
|
||||
<h2>Data Representation</h2><p>
|
||||
As described here, the object file
|
||||
format
|
||||
supports various processors with 8-bit bytes
|
||||
and either 32-bit or 64-bit architectures.
|
||||
Nevertheless, it is intended to be extensible to larger
|
||||
(or smaller) architectures.
|
||||
Object files therefore represent some control data
|
||||
with a machine-independent format,
|
||||
making it possible to identify object files and
|
||||
interpret their contents in a common way.
|
||||
Remaining data in an object file
|
||||
use the encoding of the target processor, regardless of
|
||||
the machine on which the file was created.
|
||||
<hr>
|
||||
<b>Figure 4-2: 32-Bit Data Types</b>
|
||||
<p>
|
||||
<table border=1 cellspacing=0>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Size</th>
|
||||
<th>Alignment</th>
|
||||
<th>Purpose</th>
|
||||
<tr>
|
||||
<td><code>Elf32_Addr</code></td>
|
||||
<TD align=center><code>4</code></td>
|
||||
<TD align=center><code>4</code></td>
|
||||
<td>Unsigned program address</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>Elf32_Off</code></td>
|
||||
<TD align=center><code>4</code></td>
|
||||
<TD align=center><code>4</code></td>
|
||||
<td>Unsigned file offset</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>Elf32_Half</code></td>
|
||||
<td align=center><code>2</code></td>
|
||||
<td align=center><code>2</code></td>
|
||||
<td>Unsigned medium integer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>Elf32_Word</code></td>
|
||||
<TD align=center><code>4</code></td>
|
||||
<TD align=center><code>4</code></td>
|
||||
<td>Unsigned integer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>Elf32_Sword</code></td>
|
||||
<TD align=center><code>4</code></td>
|
||||
<TD align=center><code>4</code></td>
|
||||
<td>Signed integer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>unsigned char</code></td>
|
||||
<TD align=center><code>1</code></td>
|
||||
<TD align=center><code>1</code></td>
|
||||
<td>Unsigned small integer</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
<b>64-Bit Data Types</b>
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Size</th>
|
||||
<th>Alignment</th>
|
||||
<th>Purpose</th>
|
||||
<tr>
|
||||
<td><code>Elf64_Addr</code></td>
|
||||
<TD align=center><code>8</code></td>
|
||||
<TD align=center><code>8</code></td>
|
||||
<td>Unsigned program address</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>Elf64_Off</code></td>
|
||||
<TD align=center><code>8</code></td>
|
||||
<TD align=center><code>8</code></td>
|
||||
<td>Unsigned file offset</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>Elf64_Half</code></td>
|
||||
<TD align=center><code>2</code></td>
|
||||
<TD align=center><code>2</code></td>
|
||||
<td>Unsigned medium integer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>Elf64_Word</code></td>
|
||||
<td align=center><code>4</code></td>
|
||||
<td align=center><code>4</code></td>
|
||||
<td>Unsigned integer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>Elf64_Sword</code></td>
|
||||
<td align=center><code>4</code></td>
|
||||
<td align=center><code>4</code></td>
|
||||
<td>Signed integer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>Elf64_Xword</code></td>
|
||||
<td align=center><code>8</code></td>
|
||||
<td align=center><code>8</code></td>
|
||||
<td>Unsigned long integer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>Elf64_Sxword</code></td>
|
||||
<td align=center><code>8</code></td>
|
||||
<td align=center><code>8</code></td>
|
||||
<td>Signed long integer</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>unsigned char</code></td>
|
||||
<td align=center><code>1</code></td>
|
||||
<td align=center><code>1</code></td>
|
||||
<td>Unsigned small integer</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
<hr>
|
||||
All data structures that the object file format
|
||||
defines follow the ``natural'' size and alignment guidelines
|
||||
for the relevant class.
|
||||
If necessary, data structures contain explicit padding to
|
||||
ensure 8-byte alignment for 8-byte objects,
|
||||
4-byte alignment for 4-byte objects, to force
|
||||
structure sizes to a multiple of 4 or 8, and so forth.
|
||||
Data also have suitable alignment from the beginning of the file.
|
||||
Thus, for example, a structure containing an
|
||||
<code>Elf32_Addr</code>
|
||||
member will be aligned on a 4-byte boundary within the file.
|
||||
<p>
|
||||
For portability reasons, ELF uses no bit-fields.
|
||||
<hr>
|
||||
<a href=contents.html><img src=contents.gif alt="Contents">
|
||||
<a href=ch4.eheader.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>
|
||||
180
specs/sysv-abi-update.html/ch4.reloc.html
Normal file
180
specs/sysv-abi-update.html/ch4.reloc.html
Normal file
@@ -0,0 +1,180 @@
|
||||
<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>
|
||||
1307
specs/sysv-abi-update.html/ch4.sheader.html
Normal file
1307
specs/sysv-abi-update.html/ch4.sheader.html
Normal file
File diff suppressed because it is too large
Load Diff
124
specs/sysv-abi-update.html/ch4.strtab.html
Normal file
124
specs/sysv-abi-update.html/ch4.strtab.html
Normal file
@@ -0,0 +1,124 @@
|
||||
<html>
|
||||
<title>String Table</title><p>
|
||||
<h1>String Table</h1><p>
|
||||
String table sections hold null-terminated character sequences,
|
||||
commonly called strings.
|
||||
The object file uses these strings to represent symbol and section names.
|
||||
One references a string as an index into the
|
||||
string table section.
|
||||
The first byte, which is index zero, is defined to hold
|
||||
a null character.
|
||||
Likewise, a string table's last byte is defined to hold
|
||||
a null character, ensuring null termination for all strings.
|
||||
A string whose index is zero specifies
|
||||
either no name or a null name, depending on the context.
|
||||
An empty string table section is permitted; its section header's <code>sh_size</code>
|
||||
member would contain zero.
|
||||
Non-zero indexes are invalid for an empty string table.
|
||||
<p>
|
||||
A section header's <code>sh_name</code>
|
||||
member holds an index into the section header string table
|
||||
section, as designated by the <code>e_shstrndx</code>
|
||||
member of the ELF header.
|
||||
The following figures show a string table with 25 bytes
|
||||
and the strings associated with various indexes.
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<th>Index</th>
|
||||
<th>+0</th>
|
||||
<th>+1</th>
|
||||
<th>+2</th>
|
||||
<th>+3</th>
|
||||
<th>+4</th>
|
||||
<th>+5</th>
|
||||
<th>+6</th>
|
||||
<th>+7</th>
|
||||
<th>+8</th>
|
||||
<th>+9</th>
|
||||
<tr>
|
||||
<td align=right><b>0</b></td>
|
||||
<td align=center width="50"><code>\0</code></td>
|
||||
<td align=center width="50"><code>n</code></td>
|
||||
<td align=center width="50"><code>a</code></td>
|
||||
<td align=center width="50"><code>m</code></td>
|
||||
<td align=center width="50"><code>e</code></td>
|
||||
<td align=center width="50"><code>.</code></td>
|
||||
<td align=center width="50"><code>\0</code></td>
|
||||
<td align=center width="50"><code>V</code></td>
|
||||
<td align=center width="50"><code>a</code></td>
|
||||
<td align=center width="50"><code>r</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align=right><b>10</b></td>
|
||||
<td align=center width="50"><code>i</code></td>
|
||||
<td align=center width="50"><code>a</code></td>
|
||||
<td align=center width="50"><code>b</code></td>
|
||||
<td align=center width="50"><code>l</code></td>
|
||||
<td align=center width="50"><code>e</code></td>
|
||||
<td align=center width="50"><code>\0</code></td>
|
||||
<td align=center width="50"><code>a</code></td>
|
||||
<td align=center width="50"><code>b</code></td>
|
||||
<td align=center width="50"><code>l</code></td>
|
||||
<td align=center width="50"><code>e</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align=right><b>20</b></td>
|
||||
<td align=center width="50"><code>\0</code></td>
|
||||
<td align=center width="50"><code>\0</code></td>
|
||||
<td align=center width="50"><code>x</code></td>
|
||||
<td align=center width="50"><code>x</code></td>
|
||||
<td align=center width="50"><code>\0</code></td>
|
||||
<td colspan=5><code> </code></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
<b>Figure 4-15: String Table Indexes</b>
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<th>Index</th>
|
||||
<th>String</th>
|
||||
<tr>
|
||||
<td align=right>0</td>
|
||||
<td><i>none</i></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align=right>1</td>
|
||||
<td>name.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align=right>7</td>
|
||||
<td>Variable</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align=right>11</td>
|
||||
<td>able</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align=right>16</td>
|
||||
<td>able</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align=right>24</td>
|
||||
<td><i>null string</i></td>
|
||||
</tr>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
<p>
|
||||
As the example shows, a string table index may refer
|
||||
to any byte in the section.
|
||||
A string may appear more than once;
|
||||
references to substrings may exist;
|
||||
and a single string may be referenced multiple times.
|
||||
Unreferenced strings also are allowed.
|
||||
<hr>
|
||||
<a href=ch4.sheader.html><img src=previous.gif alt="Previous"></a>
|
||||
<a href=contents.html><img src=contents.gif alt="Contents"></a>
|
||||
<a href=ch4.symtab.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>
|
||||
592
specs/sysv-abi-update.html/ch4.symtab.html
Normal file
592
specs/sysv-abi-update.html/ch4.symtab.html
Normal file
@@ -0,0 +1,592 @@
|
||||
<html>
|
||||
<title>Symbol Table</title><p>
|
||||
<h1>Symbol Table</h1><p>
|
||||
An object file's symbol table holds information
|
||||
needed to locate and relocate a program's symbolic
|
||||
definitions and references.
|
||||
A symbol table index is a subscript into this array.
|
||||
Index 0 both designates the first entry in the table
|
||||
and serves as the undefined symbol index. The contents of the
|
||||
initial entry are specified later in this section.
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<th>Name</th>
|
||||
<th>Value</th>
|
||||
<tr>
|
||||
<td><code>STN_UNDEF</code></td>
|
||||
<td align=center><code>0</code></td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
A symbol table entry has the following format.
|
||||
<hr>
|
||||
<b>Figure 4-16: Symbol Table Entry</b>
|
||||
<p>
|
||||
<pre>
|
||||
<code>
|
||||
typedef struct {
|
||||
Elf32_Word st_name;
|
||||
Elf32_Addr st_value;
|
||||
Elf32_Word st_size;
|
||||
unsigned char st_info;
|
||||
unsigned char st_other;
|
||||
Elf32_Half st_shndx;
|
||||
} Elf32_Sym;
|
||||
|
||||
typedef struct {
|
||||
Elf64_Word st_name;
|
||||
unsigned char st_info;
|
||||
unsigned char st_other;
|
||||
Elf64_Half st_shndx;
|
||||
Elf64_Addr st_value;
|
||||
Elf64_Xword st_size;
|
||||
} Elf64_Sym;
|
||||
</pre>
|
||||
</code>
|
||||
<hr>
|
||||
<p>
|
||||
<DL COMPACT>
|
||||
<p><dt><code>st_name</code><dd>
|
||||
This member holds an index into the object file's
|
||||
symbol string table, which
|
||||
holds the character representations of the symbol names.
|
||||
If the value is non-zero, it represents a string table
|
||||
index that gives the symbol name.
|
||||
Otherwise, the symbol table entry has no name.
|
||||
</dl>
|
||||
<hr>
|
||||
<img src=warning.gif alt="NOTE:">
|
||||
External C symbols have the same names in C
|
||||
and object files' symbol tables.
|
||||
<hr><p>
|
||||
<DL COMPACT>
|
||||
<p><dt><code>st_value</code><dd>
|
||||
This member gives the value of the associated symbol.
|
||||
Depending on the context, this may be an absolute value,
|
||||
an address, and so on; details appear below.
|
||||
<p><dt><code>st_size</code><dd>
|
||||
Many symbols have associated sizes.
|
||||
For example, a data object's size is the number
|
||||
of bytes contained in the object.
|
||||
This member holds 0 if the symbol has no size or an unknown size.
|
||||
<p><dt><code>st_info</code><dd>
|
||||
This member specifies the symbol's type and binding attributes.
|
||||
A list of the values and meanings appears below.
|
||||
The following code shows how to manipulate the values for
|
||||
both 32 and 64-bit objects.
|
||||
<hr>
|
||||
<PRE>
|
||||
#define ELF32_ST_BIND(i) ((i)>>4)
|
||||
#define ELF32_ST_TYPE(i) ((i)&0xf)
|
||||
#define ELF32_ST_INFO(b,t) (((b)<<4)+((t)&0xf))
|
||||
|
||||
#define ELF64_ST_BIND(i) ((i)>>4)
|
||||
#define ELF64_ST_TYPE(i) ((i)&0xf)
|
||||
#define ELF64_ST_INFO(b,t) (((b)<<4)+((t)&0xf))
|
||||
</PRE>
|
||||
<hr>
|
||||
<a name=st_other></a>
|
||||
<p><dt><code>st_other</code><dd>
|
||||
This member currently specifies a symbol's visibility.
|
||||
A list of the values and meanings appears <a href=#visibility>below</a>.
|
||||
The following code shows how to manipulate the values for
|
||||
both 32 and 64-bit objects. Other bits contain 0 and have
|
||||
no defined meaning.
|
||||
<hr>
|
||||
<PRE>
|
||||
#define ELF32_ST_VISIBILITY(o) ((o)&0x3)
|
||||
#define ELF64_ST_VISIBILITY(o) ((o)&0x3)
|
||||
</PRE>
|
||||
<hr>
|
||||
<p><dt><code>st_shndx</code><dd>
|
||||
Every symbol table entry is <i>defined</i> in relation
|
||||
to some section. This member holds the relevant
|
||||
section header table index.
|
||||
As the <code>sh_link</code> and <code>sh_info</code> interpretation
|
||||
<a href=ch4.sheader.html#sh_link>table</a>
|
||||
and the related text describe,
|
||||
some section indexes indicate special meanings.
|
||||
<p>
|
||||
If this member contains <code>SHN_XINDEX</code>,
|
||||
then the actual section header index is too large to fit in this field.
|
||||
The actual value is contained in the associated
|
||||
section of type <code>SHT_SYMTAB_SHNDX</code>.
|
||||
</dl>
|
||||
<p>
|
||||
A symbol's binding determines the linkage visibility
|
||||
and behavior.
|
||||
<hr>
|
||||
<b>Figure 4-17: Symbol Binding</b>
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<th>Name</th>
|
||||
<th>Value</th>
|
||||
<tr>
|
||||
<td><code>STB_LOCAL</code></td>
|
||||
<td align=right><code>0</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STB_GLOBAL</code></td>
|
||||
<td align=right><code>1</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STB_WEAK</code></td>
|
||||
<td align=right><code>2</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STB_LOOS</code></td>
|
||||
<td align=right><code>10</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STB_HIOS</code></td>
|
||||
<td align=right><code>12</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STB_LOPROC</code></td>
|
||||
<td align=right><code>13</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STB_HIPROC</code></td>
|
||||
<td align=right><code>15</code></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
<dl compact>
|
||||
<p><dt><code>STB_LOCAL</code><dd>
|
||||
Local symbols are not visible outside the object file
|
||||
containing their definition.
|
||||
Local symbols of the same name may exist in
|
||||
multiple files without interfering with each other.
|
||||
<p><dt><code>STB_GLOBAL</code><dd>
|
||||
Global symbols are visible to all object files being combined.
|
||||
One file's definition of a global symbol will satisfy
|
||||
another file's undefined reference to the same global symbol.
|
||||
<p><dt><code>STB_WEAK</code><dd>
|
||||
Weak symbols resemble global symbols, but their
|
||||
definitions have lower precedence.
|
||||
<p><dt><code>STB_LOOS</code> through <code>STB_HIOS</code><dd>
|
||||
Values in this inclusive range
|
||||
are reserved for operating system-specific semantics.
|
||||
<p><dt><code>STB_LOPROC</code> through <code>STB_HIPROC</code><dd>
|
||||
Values in this inclusive range
|
||||
are reserved for processor-specific semantics. If meanings are
|
||||
specified, the processor supplement explains them.
|
||||
</dl>
|
||||
<p>
|
||||
Global and weak symbols differ in two major ways.
|
||||
<ul>
|
||||
<p><li>
|
||||
When the link editor combines several relocatable object files,
|
||||
it does not allow multiple definitions of <code>STB_GLOBAL</code>
|
||||
symbols with the same name.
|
||||
On the other hand, if a defined global symbol exists,
|
||||
the appearance of a weak symbol with the same name
|
||||
will not cause an error.
|
||||
The link editor honors the global definition and ignores
|
||||
the weak ones.
|
||||
Similarly, if a common symbol exists
|
||||
(that is, a symbol whose <code>st_shndx</code>
|
||||
field holds <code>SHN_COMMON</code>),
|
||||
the appearance of a weak symbol with the same name will
|
||||
not cause an error.
|
||||
The link editor honors the common definition and
|
||||
ignores the weak ones.
|
||||
<p><li>
|
||||
When the link editor searches archive libraries [see ``Archive File''
|
||||
in Chapter 7],
|
||||
it extracts archive members that contain definitions of
|
||||
undefined global symbols.
|
||||
The member's definition may be either a global or a weak symbol.
|
||||
The link editor does not
|
||||
extract archive members to resolve undefined weak symbols.
|
||||
Unresolved weak symbols have a zero value.
|
||||
</ul>
|
||||
<a name="weak_note"></a>
|
||||
<hr>
|
||||
<img src=warning.gif alt="NOTE:">
|
||||
The behavior of weak symbols in areas not specified by this document is
|
||||
implementation defined.
|
||||
Weak symbols are intended primarily for use in system software.
|
||||
Applications using weak symbols are unreliable
|
||||
since changes in the runtime environment
|
||||
might cause the execution to fail.
|
||||
<hr><p>
|
||||
In each symbol table, all symbols with <code>STB_LOCAL</code>
|
||||
binding precede the weak and global symbols.
|
||||
As
|
||||
<a href=ch4.sheader.html>``Sections''</a>,
|
||||
above describes,
|
||||
a symbol table section's <code>sh_info</code>
|
||||
section header member holds the symbol table index
|
||||
for the first non-local symbol.
|
||||
<p>
|
||||
A symbol's type provides a general classification for
|
||||
the associated entity.
|
||||
<hr>
|
||||
<b>Figure 4-18: Symbol Types</b>
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<th>Name</th>
|
||||
<th>Value</th>
|
||||
<tr>
|
||||
<td><code>STT_NOTYPE</code></td>
|
||||
<td align=right><code>0</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STT_OBJECT</code></td>
|
||||
<td align=right><code>1</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STT_FUNC</code></td>
|
||||
<td align=right><code>2</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STT_SECTION</code></td>
|
||||
<td align=right><code>3</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STT_FILE</code></td>
|
||||
<td align=right><code>4</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STT_COMMON</code></td>
|
||||
<td align=right><code>5</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STT_TLS</code></td>
|
||||
<td align=right><code>6</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STT_LOOS</code></td>
|
||||
<td align=right><code>10</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STT_HIOS</code></td>
|
||||
<td align=right><code>12</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STT_LOPROC</code></td>
|
||||
<td align=right><code>13</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STT_HIPROC</code></td>
|
||||
<td align=right><code>15</code></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
<p>
|
||||
<DL COMPACT>
|
||||
<p><dt><code>STT_NOTYPE</code><dd>
|
||||
The symbol's type is not specified.
|
||||
<p><dt><code>STT_OBJECT</code><dd>
|
||||
The symbol is associated with a data object,
|
||||
such as a variable, an array, and so on.
|
||||
<p><dt><code>STT_FUNC</code><dd>
|
||||
The symbol is associated with a function or other executable code.
|
||||
<p><dt><code>STT_SECTION</code><dd>
|
||||
The symbol is associated with a section.
|
||||
Symbol table entries of this type exist primarily for relocation
|
||||
and normally have <code>STB_LOCAL</code> binding.
|
||||
<p><dt><code>STT_FILE</code><dd>
|
||||
Conventionally, the symbol's name gives the name of
|
||||
the source file associated with the object file.
|
||||
A file symbol has <code>STB_LOCAL</code>
|
||||
binding, its section index is <code>SHN_ABS</code>,
|
||||
and it precedes the other <code>STB_LOCAL</code>
|
||||
symbols for the file, if it is present.
|
||||
<p><dt><code>STT_COMMON</code><dd>
|
||||
The symbol labels an uninitialized common block.
|
||||
See <a href=#stt_common>below</a> for details.
|
||||
<a name=stt_tls></a>
|
||||
<p><dt><code>STT_TLS</code><dd>
|
||||
The symbol specifies a <i>Thread-Local Storage</i> entity.
|
||||
When defined, it gives the assigned offset for the symbol,
|
||||
not the actual address.
|
||||
Symbols of type <code>STT_TLS</code> can be referenced
|
||||
by only special thread-local storage relocations
|
||||
and thread-local storage relocations can only reference
|
||||
symbols with type <code>STT_TLS</code>.
|
||||
Implementation need not support thread-local storage.
|
||||
<p><dt><code>STT_LOOS</code> through <code>STT_HIOS</code><dd>
|
||||
Values in this inclusive range
|
||||
are reserved for operating system-specific semantics.
|
||||
<p><dt><code>STT_LOPROC</code> through <code>STT_HIPROC</code><dd>
|
||||
Values in this inclusive range
|
||||
are reserved for processor-specific semantics.
|
||||
If meanings are specified, the processor supplement explains
|
||||
them.
|
||||
</dl>
|
||||
<p>
|
||||
Function symbols (those with type
|
||||
<code>STT_FUNC</code>) in shared object files have special significance.
|
||||
When another object file references a function from
|
||||
a shared object, the link editor automatically creates a procedure
|
||||
linkage table entry for the referenced symbol.
|
||||
Shared object symbols with types other than
|
||||
<code>STT_FUNC</code> will not
|
||||
be referenced automatically through the procedure linkage table.
|
||||
<a name=stt_common></a>
|
||||
<p>
|
||||
Symbols with type <code>STT_COMMON</code> label uninitialized
|
||||
common blocks. In relocatable objects, these symbols are
|
||||
not allocated and must have the special section index
|
||||
<code>SHN_COMMON</code> (see <a href=#shn_common>below</a>).
|
||||
In shared objects and executables these symbols must be
|
||||
allocated to some section in the defining object.
|
||||
<p>
|
||||
In relocatable objects, symbols with type <code>STT_COMMON</code>
|
||||
are treated just as other symbols with index <code>SHN_COMMON</code>.
|
||||
If the link-editor allocates space for the <code>SHN_COMMON</code>
|
||||
symbol in an output section of the object it is producing, it
|
||||
must preserve the type of the output symbol as <code>STT_COMMON</code>.
|
||||
<p>
|
||||
When the dynamic linker encounters a reference to a symbol
|
||||
that resolves to a definition of type <code>STT_COMMON</code>,
|
||||
it may (but is not required to) change its symbol resolution
|
||||
rules as follows: instead of binding the reference to
|
||||
the first symbol found with the given name, the dynamic linker searches
|
||||
for the first symbol with that name with type other
|
||||
than <code>STT_COMMON</code>. If no such symbol is found,
|
||||
it looks for the <code>STT_COMMON</code> definition of that
|
||||
name that has the largest size.
|
||||
<a name=visibility></a>
|
||||
<p>
|
||||
A symbol's visibility, although it may be specified in a relocatable
|
||||
object, defines how that symbol may be accessed once it has
|
||||
become part of an executable or shared object.
|
||||
<hr>
|
||||
<b>Figure 4-19: Symbol Visibility</b>
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<th>Name</th>
|
||||
<th>Value</th>
|
||||
<tr>
|
||||
<td><code>STV_DEFAULT</code></td>
|
||||
<td align=right><code>0</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STV_INTERNAL</code></td>
|
||||
<td align=right><code>1</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STV_HIDDEN</code></td>
|
||||
<td align=right><code>2</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>STV_PROTECTED</code></td>
|
||||
<td align=right><code>3</code></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
<p>
|
||||
<DL COMPACT>
|
||||
<p><dt><code>STV_DEFAULT</code><dd>
|
||||
The visibility of symbols with the <code>STV_DEFAULT</code>
|
||||
attribute is as specified by the symbol's binding type.
|
||||
That is, global and weak symbols are visible
|
||||
outside of their defining <i>component</i>
|
||||
(executable file or shared object).
|
||||
Local symbols are <i>hidden</i>, as described below.
|
||||
Global and weak symbols are also <i>preemptable</i>,
|
||||
that is, they may by preempted by definitions of the same
|
||||
name in another component.
|
||||
<hr>
|
||||
<img src=warning.gif alt="NOTE:">
|
||||
An implementation may restrict the set of global and weak
|
||||
symbols that are externally visible.
|
||||
<hr><p>
|
||||
<p><dt><code>STV_PROTECTED</code><dd>
|
||||
A symbol defined in the current component is <i>protected</i>
|
||||
if it is visible in other components but not preemptable,
|
||||
meaning that any reference to such a symbol from within the
|
||||
defining component must be resolved to the definition in
|
||||
that component, even if there is a definition in another
|
||||
component that would preempt by the default rules.
|
||||
A symbol with <code>STB_LOCAL</code> binding may not have
|
||||
<code>STV_PROTECTED</code> visibility.
|
||||
<a name=protected_resolution></a>
|
||||
If a symbol definition with <code>STV_PROTECTED</code> visibility
|
||||
from a shared object is taken as resolving a reference
|
||||
from an executable or another shared object,
|
||||
the <code>SHN_UNDEF</code> symbol table entry created
|
||||
has <code>STV_DEFAULT</code> visibility.
|
||||
<hr>
|
||||
<img src=warning.gif alt="NOTE:">
|
||||
<a name=protected_note></a>
|
||||
The presence of the <code>STV_PROTECTED</code> flag on a symbol
|
||||
in a given load module does not affect the symbol resolution
|
||||
rules for references to that symbol from outside the containing
|
||||
load module.
|
||||
<hr><p>
|
||||
<p><dt><code>STV_HIDDEN</code><dd>
|
||||
A symbol defined in the current component is <i>hidden</i>
|
||||
if its name is not visible to other components. Such a symbol
|
||||
is necessarily protected. This attribute may be used to
|
||||
control the external interface of a component. Note that
|
||||
an object named by such a symbol may still be referenced
|
||||
from another component if its address is passed outside.
|
||||
<p>
|
||||
A hidden symbol contained in a relocatable object must be
|
||||
either removed or converted to <code>STB_LOCAL</code> binding
|
||||
by the link-editor when the relocatable object is included in an
|
||||
executable file or shared object.
|
||||
<p><dt><code>STV_INTERNAL</code><dd>
|
||||
The meaning of this visibility attribute may be defined by processor
|
||||
supplements to further constrain hidden symbols. A processor
|
||||
supplement's definition should be such that generic tools
|
||||
can safely treat internal symbols as hidden.
|
||||
<p>
|
||||
An internal symbol contained in a relocatable object must be
|
||||
either removed or converted to <code>STB_LOCAL</code> binding
|
||||
by the link-editor when the relocatable object is included in an
|
||||
executable file or shared object.
|
||||
</dl>
|
||||
<p>
|
||||
None of the visibility attributes affects resolution of symbols
|
||||
within an executable or shared object during link-editing -- such
|
||||
resolution is controlled by the binding type. Once the link-editor
|
||||
has chosen its resolution, these attributes impose two requirements,
|
||||
both based on the fact that references in the code being linked may
|
||||
have been optimized to take advantage of the attributes.
|
||||
<ul>
|
||||
<li>
|
||||
First, all of the non-default visibility attributes, when applied
|
||||
to a symbol reference, imply that a definition to satisfy that
|
||||
reference must be provided within the current executable or
|
||||
shared object. If such a symbol reference has no definition within the
|
||||
component being linked, then the reference must have
|
||||
<code>STB_WEAK</code> binding and is resolved to zero.
|
||||
<li>
|
||||
Second, if any reference to or definition of a name is a symbol with
|
||||
a non-default visibility attribute, the visibility attribute
|
||||
must be propagated to the resolving symbol in the linked object.
|
||||
If different visibility attributes are specified for distinct
|
||||
references to or definitions of a symbol, the most constraining
|
||||
visibility attribute must be propagated to the resolving symbol
|
||||
in the linked object. The attributes, ordered from least
|
||||
to most constraining, are: <code>STV_PROTECTED</code>,
|
||||
<code>STV_HIDDEN</code> and <code>STV_INTERNAL</code>.
|
||||
</ul>
|
||||
<p>
|
||||
If a symbol's value refers to a
|
||||
specific location within a section,
|
||||
its section index member, <code>st_shndx</code>,
|
||||
holds an index into the section header table.
|
||||
As the section moves during relocation, the symbol's value
|
||||
changes as well, and references to the symbol
|
||||
continue to ``point'' to the same location in the program.
|
||||
Some special section index values give other semantics.
|
||||
<DL COMPACT>
|
||||
<p><dt><code>SHN_ABS</code><dd>
|
||||
The symbol has an absolute value that will not change
|
||||
because of relocation.
|
||||
<a name=shn_common></a>
|
||||
<p><dt><code>SHN_COMMON</code><dd>
|
||||
The symbol labels a common block that has not yet been allocated.
|
||||
The symbol's value gives alignment constraints,
|
||||
similar to a section's
|
||||
<code>sh_addralign</code> member.
|
||||
The link editor will allocate the storage for the symbol
|
||||
at an address that is a multiple of
|
||||
<code>st_value</code>.
|
||||
The symbol's size tells how many bytes are required.
|
||||
Symbols with section index <code>SHN_COMMON</code> may
|
||||
appear only in relocatable objects.
|
||||
<p><dt><code>SHN_UNDEF</code><dd>
|
||||
This section table index means the symbol is undefined.
|
||||
When the link editor combines this object file with
|
||||
another that defines the indicated symbol,
|
||||
this file's references to the symbol will be linked
|
||||
to the actual definition.
|
||||
<p><dt><code>SHN_XINDEX</code><dd>
|
||||
<a name=many_sections></a>
|
||||
This value is an escape value.
|
||||
It indicates that the symbol refers to a specific location within a section,
|
||||
but that the section header index for that section is too large to be
|
||||
represented directly in the symbol table entry.
|
||||
The actual section header index is found in the associated
|
||||
<code>SHT_SYMTAB_SHNDX</code> section.
|
||||
The entries in that section correspond one to one
|
||||
with the entries in the symbol table.
|
||||
Only those entries in <code>SHT_SYMTAB_SHNDX</code>
|
||||
that correspond to symbol table entries with <code>SHN_XINDEX</code>
|
||||
will hold valid section header indexes;
|
||||
all other entries will have value <code>0</code>.
|
||||
</dl>
|
||||
<p>
|
||||
The symbol table entry for index 0 (<code>STN_UNDEF</code>)
|
||||
is reserved; it holds the following.
|
||||
<hr>
|
||||
<b>Figure 4-20: Symbol Table Entry:Index 0</b>
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<th><b>Name</b></th>
|
||||
<th><b>Value</b></th>
|
||||
<th><b>Note</b></th>
|
||||
<tr>
|
||||
<td><code>st_name</code></td>
|
||||
<td align=center><code>0</code></td>
|
||||
<td>No name</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>st_value</code></td>
|
||||
<td align=center><code>0</code></td>
|
||||
<td>Zero value</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>st_size</code></td>
|
||||
<td align=center><code>0</code></td>
|
||||
<td>No size</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>st_info</code></td>
|
||||
<td align=center><code>0</code></td>
|
||||
<td>No type, local binding</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>st_other</code></td>
|
||||
<td align=center><code>0</code></td>
|
||||
<td>Default visibility</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>st_shndx</code></td>
|
||||
<td align=center><code>SHN_UNDEF</code></td>
|
||||
<td>No section</td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
<a name=symbol_values></a>
|
||||
<h2>Symbol Values</h2>
|
||||
Symbol table entries for different object file types have
|
||||
slightly different interpretations for the <code>st_value</code> member.
|
||||
<ul>
|
||||
<p><li>
|
||||
In relocatable files, <code>st_value</code> holds alignment constraints for a symbol
|
||||
whose section index is <code>SHN_COMMON</code>.
|
||||
<p><li>
|
||||
In relocatable files, <code>st_value</code> holds
|
||||
a section offset for a defined symbol.
|
||||
<code>st_value</code> is an offset from the beginning of the section that
|
||||
<code>st_shndx</code> identifies.
|
||||
<p><li>
|
||||
In executable and shared object files,
|
||||
<code>st_value</code> holds a virtual address.
|
||||
To make these files' symbols more useful
|
||||
for the dynamic linker, the section offset (file interpretation)
|
||||
gives way to a virtual address (memory interpretation)
|
||||
for which the section number is irrelevant.
|
||||
</ul>
|
||||
Although the symbol table values have similar meanings
|
||||
for different object files, the data allows
|
||||
efficient access by the appropriate programs.
|
||||
<hr>
|
||||
<a href=ch4.strtab.html><img src=previous.gif alt="Previous"></a>
|
||||
<a href=contents.html><img src=contents.gif alt="Contents"></a>
|
||||
<a href=ch4.reloc.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>
|
||||
1250
specs/sysv-abi-update.html/ch5.dynamic.html
Normal file
1250
specs/sysv-abi-update.html/ch5.dynamic.html
Normal file
File diff suppressed because it is too large
Load Diff
60
specs/sysv-abi-update.html/ch5.intro.html
Normal file
60
specs/sysv-abi-update.html/ch5.intro.html
Normal file
@@ -0,0 +1,60 @@
|
||||
<html>
|
||||
<title>Chapter 5: Program Loading and Dynamic Linking</title><p>
|
||||
<h1>Introduction</h1><p>
|
||||
This section describes the object file
|
||||
information and system actions that create running programs.
|
||||
Some information here applies to all systems;
|
||||
information specific to one processor resides in
|
||||
sections marked accordingly.
|
||||
<p>
|
||||
Executable and shared object files statically represent programs.
|
||||
To execute such programs, the system uses the files to create
|
||||
dynamic program representations, or process images.
|
||||
As section ''Virtual Address Space'' in Chapter 3 of the
|
||||
processor supplement describes, a process image has segments that
|
||||
hold its text, data, stack, and so on. This chapter's major sections
|
||||
discuss the following:
|
||||
<ul>
|
||||
<li>
|
||||
<a href=ch5.pheader.html>Program Header.</a>
|
||||
This section complements Chapter 4, describing
|
||||
object file structures that relate directly to program execution.
|
||||
The primary data structure, a program header table, locates
|
||||
segment images within the file and contains other information
|
||||
necessary to create the memory image for the program.
|
||||
<li>
|
||||
<a href=ch5.prog_loading.html>Program Loading.</a>
|
||||
Given an object file, the system must load
|
||||
it into memory for the program to run.
|
||||
<li>
|
||||
<a href=ch5.dynamic.html>Dynamic linking.</a>
|
||||
After the system loads the program it must complete
|
||||
the process image by resolving symbolic references among the object
|
||||
files that compose the process.
|
||||
</ul>
|
||||
<hr>
|
||||
<img src=warning.gif alt="NOTE:">
|
||||
The processor supplement defines a naming convention for ELF constants
|
||||
that have processor ranges specified. Names such as <code>DT_</code>,
|
||||
<code>PT_</code>,
|
||||
for processor specific extensions, incorporate the name of the
|
||||
processor: <code>DT_M32_SPECIAL</code>, for example.
|
||||
Pre-existing processor
|
||||
extensions not using this convention will be supported.
|
||||
<table>
|
||||
<th>Pre-Existing Extensions</th>
|
||||
<tr>
|
||||
<td><code>DT_JUMP_REL</code></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
<a href=ch4.reloc.html><img src=previous.gif alt="Previous"></a>
|
||||
<a href=contents.html><img src=contents.gif alt="Contents"></a>
|
||||
<a href=ch5.pheader.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>
|
||||
680
specs/sysv-abi-update.html/ch5.pheader.html
Normal file
680
specs/sysv-abi-update.html/ch5.pheader.html
Normal file
@@ -0,0 +1,680 @@
|
||||
<html>
|
||||
<title>Program Header</title><p>
|
||||
<h1>Program Header</h1><p>
|
||||
An executable or shared object file's program header table
|
||||
is an array of structures, each describing a segment or
|
||||
other information the system needs to prepare the program for execution.
|
||||
An object file <i>segment</i> contains one or more <i>sections</i>,
|
||||
as
|
||||
<a href=#segment_contents>``Segment Contents''</a>
|
||||
describes below.
|
||||
Program headers are meaningful only for executable
|
||||
and shared object files.
|
||||
A file specifies its own program header size with the ELF header's
|
||||
<code>e_phentsize</code> and <code>e_phnum</code> members.
|
||||
See
|
||||
<a href=ch4.eheader.html>``ELF Header''</a> in Chapter 4
|
||||
for more information.
|
||||
<hr>
|
||||
<b>Figure 5-1: Program Header</b>
|
||||
<p>
|
||||
<pre>
|
||||
<code>
|
||||
typedef struct {
|
||||
Elf32_Word p_type;
|
||||
Elf32_Off p_offset;
|
||||
Elf32_Addr p_vaddr;
|
||||
Elf32_Addr p_paddr;
|
||||
Elf32_Word p_filesz;
|
||||
Elf32_Word p_memsz;
|
||||
Elf32_Word p_flags;
|
||||
Elf32_Word p_align;
|
||||
} Elf32_Phdr;
|
||||
|
||||
typedef struct {
|
||||
Elf64_Word p_type;
|
||||
Elf64_Word p_flags;
|
||||
Elf64_Off p_offset;
|
||||
Elf64_Addr p_vaddr;
|
||||
Elf64_Addr p_paddr;
|
||||
Elf64_Xword p_filesz;
|
||||
Elf64_Xword p_memsz;
|
||||
Elf64_Xword p_align;
|
||||
} Elf64_Phdr;
|
||||
</pre>
|
||||
</code>
|
||||
<dl compact>
|
||||
<p><dt><code>p_type</code><dd>
|
||||
This member tells what kind of segment this array element
|
||||
describes or how to interpret the array element's information.
|
||||
Type values and their meanings appear
|
||||
<a href=#p_type>below</a>.
|
||||
<p><dt><code>p_offset</code><dd>
|
||||
This member gives the offset from the beginning of the
|
||||
file at which the first byte of the segment resides.
|
||||
<p><dt><code>p_vaddr</code><dd>
|
||||
This member gives the virtual address at which
|
||||
the first byte of the segment resides in memory.
|
||||
<p><dt><code>p_paddr</code><dd>
|
||||
On systems for which physical addressing is relevant,
|
||||
this member is reserved for the segment's physical address.
|
||||
Because System V ignores physical addressing
|
||||
for application programs, this member has unspecified
|
||||
contents for executable files and shared objects.
|
||||
<p><dt><code>p_filesz</code><dd>
|
||||
This member gives the number of bytes in the file image of
|
||||
the segment; it may be zero.
|
||||
<p><dt><code>p_memsz</code><dd>
|
||||
This member gives the number of bytes in the memory image of
|
||||
the segment; it may be zero.
|
||||
<p><dt><code>p_flags</code><dd>
|
||||
This member gives flags relevant to the segment.
|
||||
Defined flag values appear
|
||||
<a href=#p_flags>below</a>.
|
||||
<p><dt><code>p_align</code><dd>
|
||||
As ``Program Loading'' describes in this chapter of the processor
|
||||
supplement,
|
||||
loadable process segments must have congruent values for
|
||||
<code>p_vaddr</code> and <code>p_offset</code>, modulo the page size.
|
||||
This member gives the value to which the
|
||||
segments are aligned in memory and in the file.
|
||||
Values 0 and 1 mean no alignment is required.
|
||||
Otherwise, <code>p_align</code>
|
||||
should be a positive, integral power of 2, and <code>p_vaddr</code>
|
||||
should equal <code>p_offset</code>,
|
||||
modulo <code>p_align</code>.
|
||||
</dl>
|
||||
<p>
|
||||
Some entries describe process segments; others
|
||||
give supplementary information and do not contribute to
|
||||
the process image.
|
||||
Segment entries may appear in any order, except as
|
||||
explicitly noted
|
||||
<a href=#p_type>below</a>.
|
||||
Defined type values follow;
|
||||
other values are reserved for future use.
|
||||
<a name="p_type"></a>
|
||||
<hr>
|
||||
<b>Figure 5-2: Segment Types</b>, <code>p_type</code>
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<th><b>Name</b></th>
|
||||
<th><b>Value</b></th>
|
||||
<tr>
|
||||
<td><code>PT_NULL</code></td>
|
||||
<td align=right><code>0</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PT_LOAD</code></td>
|
||||
<td align=right><code>1</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PT_DYNAMIC</code></td>
|
||||
<td align=right><code>2</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PT_INTERP</code></td>
|
||||
<td align=right><code>3</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PT_NOTE</code></td>
|
||||
<td align=right><code>4</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PT_SHLIB</code></td>
|
||||
<td align=right><code>5</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PT_PHDR</code></td>
|
||||
<td align=right><code>6</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PT_TLS</code></td>
|
||||
<td align=right><code>7</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PT_LOOS</code></td>
|
||||
<td align=right><code>0x60000000</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PT_HIOS</code></td>
|
||||
<td align=right><code>0x6fffffff</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PT_LOPROC</code></td>
|
||||
<td align=right><code>0x70000000</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PT_HIPROC</code></td>
|
||||
<td align=right><code>0x7fffffff</code></td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
<dl compact>
|
||||
<p><dt><code>PT_NULL</code><dd>
|
||||
The array element is unused; other members' values are undefined.
|
||||
This type lets the program header table have ignored entries.
|
||||
<p><dt><code>PT_LOAD</code><dd>
|
||||
The array element specifies a loadable segment,
|
||||
described by <code>p_filesz</code> and <code>p_memsz</code>.
|
||||
The bytes from the file are mapped to the
|
||||
beginning of the memory segment.
|
||||
If the segment's memory size (<code>p_memsz</code>)
|
||||
is larger than the file size (<code>p_filesz</code>),
|
||||
the ``extra'' bytes are defined to hold the value 0
|
||||
and to follow the segment's initialized area.
|
||||
The file size may not be larger than the memory size.
|
||||
Loadable segment entries in the program header table
|
||||
appear in ascending order, sorted on the <code>p_vaddr</code> member.
|
||||
<p><dt><code>PT_DYNAMIC</code><dd>
|
||||
The array element specifies dynamic linking information.
|
||||
See
|
||||
<a href=ch5.dynamic.html#dynamic_section>``Dynamic Section''</a>
|
||||
below for more information.
|
||||
<p><dt><code>PT_INTERP</code><dd>
|
||||
The array element specifies the location and size of
|
||||
a null-terminated path name to invoke as an interpreter.
|
||||
This segment type is meaningful only for executable files
|
||||
(though it may occur for shared objects);
|
||||
it may not occur more than once in a file.
|
||||
If it is present, it must precede any loadable segment entry.
|
||||
See
|
||||
<a href=ch5.dynamic.html#interpreter>``Program Interpreter''</a>
|
||||
below for more information.
|
||||
<p><dt><code>PT_NOTE</code><dd>
|
||||
The array element specifies the location and size of
|
||||
auxiliary information.
|
||||
See
|
||||
<a href=#note_section>``Note Section''</a>
|
||||
below for more information.
|
||||
<p><dt><code>PT_SHLIB</code><dd>
|
||||
This segment type is reserved but has unspecified semantics.
|
||||
Programs that contain an array element of this type do not
|
||||
conform to the ABI.
|
||||
<p><dt><code>PT_PHDR</code><dd>
|
||||
The array element, if present, specifies the location and size of
|
||||
the program header table itself, both in the file and
|
||||
in the memory image of the program.
|
||||
This segment type may not occur more than once in a file.
|
||||
Moreover, it may occur only if the program header table is
|
||||
part of the memory image of the program.
|
||||
If it is present, it must precede any loadable segment entry.
|
||||
See
|
||||
<a href=ch5.dynamic.html#interpreter>``Program Interpreter''</a>
|
||||
below for more information.
|
||||
<a name=pt_tls></a>
|
||||
<p><dt><code>PT_TLS</code><dd>
|
||||
The array element specifies the <i>Thread-Local Storage</i> template.
|
||||
Implementations need not support this program table entry.
|
||||
See <a href=#tls>``Thread-Local Storage''</a> below for more information.
|
||||
<p><dt><code>PT_LOOS</code> through <code>PT_HIOS</code>
|
||||
<dd>
|
||||
Values in this inclusive range
|
||||
are reserved for operating system-specific semantics.
|
||||
<p><dt><code>PT_LOPROC</code> through <code>PT_HIPROC</code>
|
||||
<dd>
|
||||
Values in this inclusive range
|
||||
are reserved for processor-specific semantics.
|
||||
If meanings are specified, the processor supplement explains
|
||||
them.
|
||||
</dl>
|
||||
<hr>
|
||||
<img src=warning.gif alt="NOTE:">
|
||||
Unless specifically required elsewhere,
|
||||
all program header segment types are optional.
|
||||
A file's program header table may contain
|
||||
only those elements relevant to its contents.
|
||||
<hr>
|
||||
<a name=base_address></a>
|
||||
<h2>Base Address</h2><p>
|
||||
As ``Program Loading'' in this chapter of the processor supplement
|
||||
describes, the virtual addresses in the program headers might not
|
||||
represent the actual virtual addresses of the program's memory
|
||||
image. Executable files typically contain absolute code. To let
|
||||
the process execute correctly, the segments must reside at the
|
||||
virtual addresses used to build the executable file. On the other
|
||||
hand, shared object segments typically contain position-independent
|
||||
code. This lets a segment's virtual address change from one
|
||||
process to another, without invalidating execution behavior.
|
||||
On some platforms, while the system chooses virtual
|
||||
addresses for individual processes,
|
||||
it maintains the <i>relative</i> position of one
|
||||
segment to another within any one shared object.
|
||||
Because position-independent code on those platforms
|
||||
uses relative addressing between segments,
|
||||
the difference between virtual addresses
|
||||
in memory must match the difference between virtual addresses
|
||||
in the file. The differences between the virtual address
|
||||
of any segment in memory and the corresponding virtual address
|
||||
in the file is thus a single constant value for any one
|
||||
executable or shared object in a given process. This difference
|
||||
is the <i>base address</i>. One use of the base address is to
|
||||
relocate the memory image of the file during dynamic linking.
|
||||
<p>
|
||||
An executable or shared object file's base address (on platforms
|
||||
that support the concept)
|
||||
is calculated during execution
|
||||
from three values: the virtual memory load address, the maximum page size,
|
||||
and the lowest virtual address of a program's loadable segment.
|
||||
To compute the base address, one determines the memory address associated
|
||||
with the lowest <code>p_vaddr</code> value for a <code>PT_LOAD</code>
|
||||
segment. This address is truncated to the nearest multiple of
|
||||
the maximum page size. The corresponding <code>p_vaddr</code>
|
||||
value itself is also truncated to the nearest multiple of
|
||||
the maximum page size. The base address is the difference
|
||||
between the truncated memory address and the truncated
|
||||
<code>p_vaddr</code> value.
|
||||
<p>
|
||||
See this chapter in the processor supplement for more information
|
||||
and examples. ``Operating System Interface'' of Chapter 3
|
||||
in the processor supplement contains more information about the
|
||||
virtual address space and page size.
|
||||
<a name=segment_permissions></a>
|
||||
<h2>Segment Permissions</h2><p>
|
||||
A program to be loaded by the system must
|
||||
have at least one loadable segment (although
|
||||
this is not required by the file format).
|
||||
When the system creates loadable segments' memory images,
|
||||
it gives access permissions as specified in the <code>p_flags</code> member.
|
||||
<hr>
|
||||
<b>Figure 5-3: Segment Flag Bits, </b><code>p_flags</code>
|
||||
<p>
|
||||
<a name=p_flags></a>
|
||||
<table border cellspacing=0>
|
||||
<th><b>Name</b></th>
|
||||
<th><b>Value</b></th>
|
||||
<th><b>Meaning</b></th>
|
||||
<tr>
|
||||
<td><code>PF_X</code></td>
|
||||
<td align=right><code>0x1</code></td>
|
||||
<td>Execute</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PF_W</code></td>
|
||||
<td align=right><code>0x2</code></td>
|
||||
<td>Write</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PF_R</code></td>
|
||||
<td align=right><code>0x4</code></td>
|
||||
<td>Read</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PF_MASKOS</code></td>
|
||||
<td align=right><code>0x0ff00000</code></td>
|
||||
<td>Unspecified</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PF_MASKPROC</code></td>
|
||||
<td align=right><code>0xf0000000</code></td>
|
||||
<td>Unspecified</td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
All bits included in the <code>PF_MASKOS</code>
|
||||
mask are reserved for operating system-specific semantics.
|
||||
<p>
|
||||
All bits included in the <code>PF_MASKPROC</code>
|
||||
mask are reserved for processor-specific semantics.
|
||||
If meanings are specified, the processor supplement explains them.
|
||||
<p>
|
||||
If a permission bit is 0, that type of access is denied.
|
||||
Actual memory permissions depend on the memory management unit,
|
||||
which may vary from one system to another.
|
||||
Although all flag combinations are valid, the system may grant
|
||||
more access than requested.
|
||||
In no case, however, will a segment have write permission
|
||||
unless it is specified explicitly.
|
||||
The following table shows both the exact flag interpretation
|
||||
and the allowable flag interpretation. ABI-conforming systems may
|
||||
provide either.
|
||||
<hr>
|
||||
<b>Figure 5-4: Segment Permissions</b>
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<th><b>Flags</b></th>
|
||||
<th><b>Value</b></th>
|
||||
<th><b>Exact</b></th>
|
||||
<th><b>Allowable</b></th>
|
||||
<tr>
|
||||
<td><i>none</i></td>
|
||||
<td align=center><code>0</code></td>
|
||||
<td>All access denied</td>
|
||||
<td>All access denied</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PF_X</code></td>
|
||||
<td align=center><code>1</code></td>
|
||||
<td>Execute only</td>
|
||||
<td>Read, execute</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PF_W</code></td>
|
||||
<td align=center><code>2</code></td>
|
||||
<td>Write only</td>
|
||||
<td>Read, write, execute</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PF_W+PF_X</code></td>
|
||||
<td align=center><code>3</code></td>
|
||||
<td>Write, execute</td>
|
||||
<td>Read, write, execute</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PF_R</code></td>
|
||||
<td align=center><code>4</code></td>
|
||||
<td>Read only</td>
|
||||
<td>Read, execute</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PF_R+PF_X</code></td>
|
||||
<td align=center><code>5</code></td>
|
||||
<td>Read, execute</td>
|
||||
<td>Read, execute</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PF_R+PF_W</code></td>
|
||||
<td align=center><code>6</code></td>
|
||||
<td>Read, write</td>
|
||||
<td>Read, write, execute</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PF_R+PF_W+PF_X</code></td>
|
||||
<td align=center><code>7</code></td>
|
||||
<td>Read, write, execute</td>
|
||||
<td>Read, write, execute</td>
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
<p>
|
||||
For example, typical text segments have read and execute - but not write - permissions.
|
||||
Data segments normally have read, write, and execute permissions.
|
||||
<a name=segment_contents></a>
|
||||
<h2>Segment Contents</h2><p>
|
||||
An object file segment comprises one or more sections,
|
||||
though this fact is transparent to the program header.
|
||||
Whether the file segment holds one or many sections
|
||||
also is immaterial to program loading.
|
||||
Nonetheless, various data must be present for program
|
||||
execution, dynamic linking, and so on.
|
||||
The diagrams below illustrate segment contents in general terms.
|
||||
The order and membership of sections within a segment may vary;
|
||||
moreover, processor-specific constraints may alter the
|
||||
examples below. See the processor supplement for details.
|
||||
<p>
|
||||
Text segments contain read-only instructions and data,
|
||||
typically including the following sections described in Chapter 4.
|
||||
Other sections may also reside in loadable segments;
|
||||
these examples are not meant to give complete and
|
||||
exclusive segment contents.
|
||||
<hr>
|
||||
<b>Figure 5-5: Text Segment</b>
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<tr><td align=center><code>.text</code></td></tr>
|
||||
<tr><td align=center><code>.rodata</code></td></tr>
|
||||
<tr><td align=center><code>.hash</code></td></tr>
|
||||
<tr><td align=center><code>.dynsym</code></td></tr>
|
||||
<tr><td align=center><code>.dynstr</code></td></tr>
|
||||
<tr><td align=center><code>.plt</code></td></tr>
|
||||
<tr><td align=center><code>.rel.got</code></td></tr>
|
||||
</table>
|
||||
<hr>
|
||||
<p>
|
||||
Data segments contain writable data and instructions,
|
||||
typically including the following sections.
|
||||
<hr>
|
||||
<b>Figure 5-6: Data Segment</b>
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<tr><td align=center><code>.data</code></td></tr>
|
||||
<tr><td align=center><code>.dynamic</code></td></tr>
|
||||
<tr><td align=center><code>.got</code></td></tr>
|
||||
<tr><td align=center><code>.bss</code></td></tr>
|
||||
</table>
|
||||
<hr>
|
||||
<p>
|
||||
A <code>PT_DYNAMIC</code> program header element points at the <code>.dynamic</code>
|
||||
section, explained in
|
||||
<a href=ch5.dynamic.html#dynamic_section>``Dynamic Section''</a>
|
||||
below.
|
||||
The <code>.got</code> and <code>.plt</code>
|
||||
sections also hold information related to position-independent
|
||||
code and dynamic linking.
|
||||
Although
|
||||
the <code>.plt</code>
|
||||
appears in a text segment in the previous table, it
|
||||
may reside in a text or a data segment,
|
||||
depending on the processor.
|
||||
See ``Global Offset Table'' and ``Procedure Linkage Table''
|
||||
in this section of the processor supplement for details.
|
||||
<p>
|
||||
As
|
||||
<a href=ch4.sheader.html>``Sections''</a>
|
||||
in Chapter 4 describes,
|
||||
the <code>.bss</code> section has the type <code>SHT_NOBITS</code>.
|
||||
Although it occupies no space in the file, it contributes
|
||||
to the segment's memory image.
|
||||
Normally, these uninitialized data reside at the end of
|
||||
the segment, thereby making <code>p_memsz</code> larger
|
||||
than <code>p_filesz</code>
|
||||
in the associated program header element.
|
||||
<a name=note_section></a>
|
||||
<h2>Note Section</h2>
|
||||
Sometimes a vendor or system builder needs to mark an
|
||||
object file with special information that
|
||||
other programs will check for conformance, compatibility, etc.
|
||||
Sections of type <code>SHT_NOTE</code>
|
||||
and program header elements of type
|
||||
<code>PT_NOTE</code> can be used for this purpose.
|
||||
The note information in sections and
|
||||
program header elements holds a variable amount of entries.
|
||||
In 64-bit objects (files with <code>e_ident[EI_CLASS]</code> equal to
|
||||
<code>ELFCLASS64</code>),
|
||||
each entry is an array of 8-byte words in the format of
|
||||
the target processor.
|
||||
In 32-bit objects (files with <code>e_ident[EI_CLASS]</code> equal to
|
||||
<code>ELFCLASS32</code>),
|
||||
each entry is an array of 4-byte words in the format of
|
||||
the target processor.
|
||||
Labels appear below
|
||||
to help explain note information
|
||||
organization, but they are not part of the specification.
|
||||
<hr>
|
||||
<b>Figure 5-7: Note Information</b>
|
||||
<p>
|
||||
<table border cellspacing=0>
|
||||
<tr><td align=center><code>namesz</code></td></tr>
|
||||
<tr><td align=center><code>descsz</code></td></tr>
|
||||
<tr><td align=center><code>type</code></td></tr>
|
||||
<tr><td align=center><code>name<br>. . .</code></td></tr>
|
||||
<tr><td align=center><code>desc<br>. . .</code></td></tr>
|
||||
</table>
|
||||
<hr>
|
||||
<dl>
|
||||
<dt><code>namesz</code> and <code>name</code>
|
||||
<dd>
|
||||
The first <code>namesz</code> bytes in <code>name</code>
|
||||
contain a null-terminated character representation
|
||||
of the entry's owner or originator.
|
||||
There is no formal mechanism for avoiding name conflicts.
|
||||
By convention, vendors use their own name, such as
|
||||
<code>XYZ Computer Company</code>, as the identifier.
|
||||
If no name is present, <code>namesz</code> contains 0.
|
||||
Padding is present, if necessary, to ensure 8 or 4-byte
|
||||
alignment for the descriptor (depending on whether the
|
||||
file is a 64-bit or 32-bit object).
|
||||
Such padding is not included in <code>namesz</code>.
|
||||
<p><dt><code>descsz</code> and <code>desc</code>
|
||||
<dd>
|
||||
The first <code>descsz</code> bytes in <code>desc</code>
|
||||
hold the note descriptor. The ABI places no constraints on a
|
||||
descriptor's contents.
|
||||
If no descriptor is present, <code>descsz</code>
|
||||
contains 0.
|
||||
Padding is present, if necessary, to ensure 8 or 4-byte
|
||||
alignment for the next note entry (depending on whether the
|
||||
file is a 64-bit or 32-bit object).
|
||||
Such padding is not included in <code>descsz</code>.
|
||||
<p><dt><code>type</code>
|
||||
<dd>
|
||||
This word gives the interpretation of the descriptor.
|
||||
Each originator controls its own types; multiple
|
||||
interpretations of a single type value may exist.
|
||||
Thus, a program must recognize both the name and
|
||||
the type to recognize a descriptor.
|
||||
Types currently must be non-negative.
|
||||
The ABI does not define what descriptors mean.
|
||||
</dl>
|
||||
<p>
|
||||
To illustrate, the following note segment holds two entries.
|
||||
<hr>
|
||||
<b>Figure 5-8: Example Note Segment</b>
|
||||
<p>
|
||||
<table>
|
||||
<td>
|
||||
<table>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td><code>namesz</code></td></tr>
|
||||
<tr><td><code>descsz</code></td></tr>
|
||||
<tr><td><code>type</code></td></tr>
|
||||
<tr><td><code>name</code></td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td><code>namesz</code></td></tr>
|
||||
<tr><td><code>descsz</code></td></tr>
|
||||
<tr><td><code>type</code></td></tr>
|
||||
<tr><td><code>name</code></td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td><code>desc</code></td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
</table>
|
||||
</td>
|
||||
<td>
|
||||
<table border cellspacing=0>
|
||||
<th width=40><b>+0</b></th>
|
||||
<th width=40><b>+1</b></th>
|
||||
<th width=40><b>+2</b></th>
|
||||
<th width=40><b>+3</b></th>
|
||||
<tr><td colspan=4 align=center><code>7</code></td></tr>
|
||||
<tr><td colspan=4 align=center><code>0</code></td></tr>
|
||||
<tr><td colspan=4 align=center><code>1</code></td></tr>
|
||||
<tr>
|
||||
<td><code>x</code></td>
|
||||
<td><code>y</code></td>
|
||||
<td><code>z</code></td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>c</code></td>
|
||||
<td><code>o</code></td>
|
||||
<td><code>\0</code></td>
|
||||
<td><i>pad</i></td>
|
||||
</tr>
|
||||
<tr><td colspan=4 align=center><code>7</code></td></tr>
|
||||
<tr><td colspan=4 align=center><code>8</code></td></tr>
|
||||
<tr><td colspan=4 align=center><code>3</code></td></tr>
|
||||
<tr>
|
||||
<td><code>x</code></td>
|
||||
<td><code>y</code></td>
|
||||
<td><code>z</code></td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>c</code></td>
|
||||
<td><code>o</code></td>
|
||||
<td><code>\0</code></td>
|
||||
<td><i>pad</i></td>
|
||||
<tr><td colspan=4 align=center><i>word 0</i></td></tr>
|
||||
<tr><td colspan=4 align=center><i>word 1</i></td></tr>
|
||||
</tr>
|
||||
</table>
|
||||
</td>
|
||||
<td>
|
||||
<table>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td>No descriptor</td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
<tr><td><br></td></tr>
|
||||
</table>
|
||||
</td>
|
||||
</table>
|
||||
<hr>
|
||||
<img src=warning.gif alt="NOTE:">
|
||||
The system reserves note information with no name
|
||||
(<code>namesz==0</code>) and with a zero-length name
|
||||
(<code>name[0]=='\0'</code>) but currently defines no types.
|
||||
All other names must have at least one non-null character.
|
||||
<hr>
|
||||
<img src=warning.gif alt="NOTE:">
|
||||
Note information is optional. The presence of note information
|
||||
does not affect a program's ABI conformance, provided the
|
||||
information does not affect the program's execution behavior.
|
||||
Otherwise, the program does not conform to the ABI and has
|
||||
undefined behavior.
|
||||
<hr>
|
||||
<a name=tls></a>
|
||||
<h2>Thread-Local Storage</h2>
|
||||
To permit association of separate copies of data allocated at compile-time
|
||||
with individual threads of execution,
|
||||
thread-local storage sections
|
||||
can be used to specify the size and initial contents of such data.
|
||||
Implementations need not support thread-local storage.
|
||||
A <code>PT_TLS</code> program entry has the following members:
|
||||
<table border cellspacing=0>
|
||||
<th><b>Member</b></th>
|
||||
<th><b>Value</b></th>
|
||||
<tr>
|
||||
<td><code>p_offset</code></td>
|
||||
<td align=left>File offset of the TLS initialization image</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>p_vaddr</code></td>
|
||||
<td align=left>Virtual memory address of the TLS initialization image</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>p_paddr</code></td>
|
||||
<td align=left>reserved</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>p_filesz</code></td>
|
||||
<td align=left>Size of the TLS initialization image</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>p_memsz</code></td>
|
||||
<td align=left>Total size of the TLS template</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>p_flags</code></td>
|
||||
<td align=left><code>PF_R</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>p_align</code></td>
|
||||
<td align=left>Alignment of the TLS template</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>
|
||||
The <i>TLS template</i> is formed from the combination
|
||||
of all sections with the flag <code>SHF_TLS</code>.
|
||||
The portion of the TLS template that holds initialized data
|
||||
is the <i>TLS initialization image</i>.
|
||||
(The remaining portion of the TLS template
|
||||
is one or more sections of type <code>SHT_NOBITS</code>.)
|
||||
<hr>
|
||||
<a href=ch5.intro.html><img src=previous.gif alt="Previous"></a>
|
||||
<a href=contents.html><img src=contents.gif alt="Contents"></a>
|
||||
<a href=ch5.prog_loading.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>
|
||||
16
specs/sysv-abi-update.html/ch5.prog_loading.html
Normal file
16
specs/sysv-abi-update.html/ch5.prog_loading.html
Normal file
@@ -0,0 +1,16 @@
|
||||
<h1>Program Loading (Processor-Specific)</h1>
|
||||
<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=ch5.pheader.html><img src=previous.gif alt="Previous">
|
||||
<a href=contents.html><img src=contents.gif alt="Contents"></a>
|
||||
<a href=ch5.dynamic.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>
|
||||
BIN
specs/sysv-abi-update.html/contents.gif
Normal file
BIN
specs/sysv-abi-update.html/contents.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 223 B |
98
specs/sysv-abi-update.html/contents.html
Normal file
98
specs/sysv-abi-update.html/contents.html
Normal file
@@ -0,0 +1,98 @@
|
||||
<html>
|
||||
<title>System V Application Binary Interface - DRAFT</title>
|
||||
<h1>System V Application Binary Interface - DRAFT - 24 April 2001</h1>
|
||||
<hr>
|
||||
<h2>Contents</h2>
|
||||
<hr>
|
||||
<h3><a href=revision.html>Revision History</a></h3>
|
||||
<hr>
|
||||
<h3>Chapter 4 - Object Files</h3>
|
||||
<ul>
|
||||
<li>
|
||||
<a href=ch4.intro.html><b>Introduction</b></a>
|
||||
<li>
|
||||
<a href=ch4.intro.html#file_format>File Format</a>
|
||||
<li>
|
||||
<a href=ch4.intro.html#data_representation>Data Representation</a>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>
|
||||
<a href=ch4.eheader.html><b>ELF Header</b></a>
|
||||
<li>
|
||||
<a href=ch4.eheader.html#elfid>ELF Identification</a>
|
||||
<li>
|
||||
<a href=ch4.eheader.html#machine>Machine Information (Processor-Specific)</a>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>
|
||||
<a href=ch4.sheader.html><b>Sections</b></a>
|
||||
<li>
|
||||
<a href=ch4.sheader.html#special_sections>Special Sections</a>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>
|
||||
<a href=ch4.strtab.html><b>String Table</b></a>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>
|
||||
<a href=ch4.symtab.html><b>Symbol Table</b></a>
|
||||
<li>
|
||||
<a href=ch4.symtab.html#symbol_value>Symbol Values</a>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>
|
||||
<a href=ch4.reloc.html><b>Relocation</b></a>
|
||||
<li>
|
||||
<a href=ch4.reloc.html#reloc_types>Relocation Types (Processor-Specific)</a>
|
||||
</ul>
|
||||
<hr>
|
||||
<H3>Chapter 5 - Program Loading and Dynamic Linking</H1>
|
||||
<ul>
|
||||
<li>
|
||||
<a href=ch5.intro.html><b>Introduction</b></a>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>
|
||||
<a href=ch5.pheader.html><b>Program Header</b></a>
|
||||
<li>
|
||||
<a href=ch5.pheader.html#base_address>Base Address</a>
|
||||
<li>
|
||||
<a href=ch5.pheader.html#segment_permissions>Segment Permissions</a>
|
||||
<li>
|
||||
<a href=ch5.pheader.html#segment_contents>Segment Contents</a>
|
||||
<li>
|
||||
<a href=ch5.pheader.html#note_section>Note Section</a>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>
|
||||
<a href=ch5.prog_loading.html><b>Program Loading (Processor-Specific)</b> </a>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>
|
||||
<a href=ch5.dynamic.html><b>Dynamic Linking</b></a>
|
||||
<li>
|
||||
<a href=ch5.dynamic.html#interpreter>Program Interpreter</a>
|
||||
<li>
|
||||
<a href=ch5.dynamic.html#dynamic_linker>Dynamic Linker</a>
|
||||
<li>
|
||||
<a href=ch5.dynamic.html#dynamic_section>Dynamic Section</a>
|
||||
<li>
|
||||
<a href=ch5.dynamic.html#shobj_dependencies>Shared Object Dependencies</a>
|
||||
<li>
|
||||
<a href=ch5.dynamic.html#substitution>Substitution Sequences</a>
|
||||
<li>
|
||||
<a href=ch5.dynamic.html#got>Global Offset Table (Processor-Specific)</a>
|
||||
<li>
|
||||
<a href=ch5.dynamic.html#plt>Procedure Linkage Table (Processor-Specific)</a>
|
||||
<li>
|
||||
<a href=ch5.dynamic.html#hash>Hash Table</a>
|
||||
<li>
|
||||
<a href=ch5.dynamic.html#init_fini>Initialization and Termination Functions</a>
|
||||
</ul>
|
||||
<hr>
|
||||
<i>
|
||||
<small>
|
||||
© 1997, 1998, 1998, 1999, 2000, 2001 The Santa Cruz Operation, Inc. All rights reserved.
|
||||
</small>
|
||||
</i>
|
||||
</html>
|
||||
BIN
specs/sysv-abi-update.html/init_example.gif
Normal file
BIN
specs/sysv-abi-update.html/init_example.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.3 KiB |
BIN
specs/sysv-abi-update.html/next.gif
Normal file
BIN
specs/sysv-abi-update.html/next.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 173 B |
BIN
specs/sysv-abi-update.html/previous.gif
Normal file
BIN
specs/sysv-abi-update.html/previous.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 216 B |
200
specs/sysv-abi-update.html/revision.html
Normal file
200
specs/sysv-abi-update.html/revision.html
Normal file
@@ -0,0 +1,200 @@
|
||||
<html>
|
||||
<title>Revision History</title>
|
||||
<h1>Revision History</h1>
|
||||
<h3>First draft published May 14, 1998.</h3>
|
||||
<h3>Second draft published May 3, 1999.</h3>
|
||||
<ul>
|
||||
<li>
|
||||
New values introduced for ELF header <a href=ch4.eheader.html#e_machine><code>e_machine</code></a> field.
|
||||
<li>
|
||||
Revised language for <a href=ch4.eheader.html#osabi><code>EI_OSABI</code></a> and <a href=ch4.eheader.html#abiversion><code>EI_ABIVERSION</code></a>
|
||||
fields of the ELF header <code>e_ident</code> array.
|
||||
<li>
|
||||
New section flags <a href=ch4.sheader.html#shf_merge><code>SHF_MERGE</code></a> and <a href=ch4.sheader.html#shf_strings><code>SHF_STRINGS</code></a>
|
||||
added.
|
||||
<li>
|
||||
New values added to a symbol table entry's
|
||||
<a href=ch4.symtab.html#st_other><code>st_other</code></a>
|
||||
field to describe a symbol's
|
||||
<a href=ch4.symtab.html#visibility>visibility</a>.
|
||||
<li>
|
||||
New dynamic section tags <a href=ch5.dynamic.html#dt_runpath><code>DT_RUNPATH</code></a>
|
||||
and <a href=ch5.dynamic.html#df_flags><code>DT_FLAGS</code></a> added.
|
||||
Dynamic section tag <a href=ch5.dynamic.html#dt_rpath>
|
||||
<code>DT_RPATH</code></a> moved to level 2.
|
||||
<li>
|
||||
New semantics for <a href=ch5.dynamic.html#shobj_dependencies>shared
|
||||
object path searching</a>, including new
|
||||
<a href=ch5.dynamic.html#substitution>``Substitution Sequences''</a>.
|
||||
</ul>
|
||||
<h3>Third draft published May 12, 1999.</h3>
|
||||
<ul>
|
||||
<li>
|
||||
A new symbol type,
|
||||
<a href=ch4.symtab.html#stt_common><code>STT_COMMON</code></a>,
|
||||
has been added.
|
||||
<li>
|
||||
Added language restricting the types of objects that may contain
|
||||
symbols with the section index
|
||||
<a href=ch4.symtab.html#shn_common><code>SHN_COMMON</code></a>.
|
||||
<li>
|
||||
Dynamic section entries <code>DT_SYMBOLIC</code>,
|
||||
<code>DT_TEXTREL</code> and <code>DT_BIND_NOW</code> have
|
||||
been moved to level 2. New <code>DT_FLAGS</code>
|
||||
values
|
||||
<a href=ch5.dynamic.html#df_symbolic><code>DF_SYMBOLIC</code></a>,
|
||||
<a href=ch5.dynamic.html#df_textrel><code>DF_TEXTREL</code></a> and
|
||||
<a href=ch5.dynamic.html#df_bind_now><code>DF_BIND_NOW</code></a>
|
||||
have been added as replacements.
|
||||
<li>
|
||||
New rules for interpreting <a href=ch5.dynamic.html#tag_encodings>
|
||||
dynamic section tag encodings</a> have been added.
|
||||
<li>
|
||||
The OS and processor specific ranges for <code>DT_FLAGS</code>
|
||||
have been removed.
|
||||
<li>
|
||||
The language motivating the use of
|
||||
<a href=ch5.dynamic.html#substitution><code>DF_ORIGIN</code></a>
|
||||
has been changed.
|
||||
</ul>
|
||||
<h3>Fourth draft published July 6, 1999.</h3>
|
||||
<ul>
|
||||
<li>
|
||||
New language has been added warning about the use
|
||||
of <a href=ch4.symtab.html#weak_note>WEAK symbols</a> in
|
||||
application programs.
|
||||
<li>
|
||||
New rules have been defined for
|
||||
<a href=ch4.reloc.html#relocation_composition>composition of
|
||||
consecutive relocation entries</a> that reference the same location.
|
||||
<li>
|
||||
Language has been added clarifying the
|
||||
<a href=ch5.dynamic.html#init_order>order of execution</a> for
|
||||
functions specified by initialization and termination arrays.
|
||||
</ul>
|
||||
<h3>Fifth draft published July 21, 1999.</h3>
|
||||
<ul>
|
||||
<li>
|
||||
New <a href=ch4.sheader.html#init_array>section types</a>
|
||||
and section names added for init arrays,
|
||||
fini arrays and pre-init arrays.
|
||||
<li>
|
||||
An object may now have both
|
||||
<a href=ch5.dynamic.html#dt_init_array>
|
||||
<code>DT_INIT</code> and <code>DT_INIT_ARRAY</a> </code> entries
|
||||
(and both <code>DT_FINI</code> and <code>DT_FINI_ARRAY</code> entries).
|
||||
The relative execution order is specified.
|
||||
<li>
|
||||
The language describing the
|
||||
<a href=ch5.dynamic.html#fini_order>order of execution for termination
|
||||
functions</a> has been revised.
|
||||
<li>
|
||||
A new <a href=ch5.dynamic.html#preinit>pre-initialization</a>
|
||||
mechanism has been added.
|
||||
<li>
|
||||
It is now up to the processor supplement for each processor
|
||||
to specify whether the dynamic linker must invoke
|
||||
<a href=ch5.dynamic.html#register_init>the executable file's init and fini routines</a>.
|
||||
</ul>
|
||||
<h3>Sixth draft published September 14, 1999.</h3>
|
||||
<ul>
|
||||
<li>
|
||||
Changed the numbering of some new <a href=ch4.sheader.html#sh_type>
|
||||
section types</a> previously added to account
|
||||
for type numbers already in use in particular vendor implementations.
|
||||
<li>
|
||||
Increased the number of <a href=ch4.sheader.html#sh_flags>
|
||||
section flag bits</a> available in the OS specific range.
|
||||
</ul>
|
||||
<h3>Seventh draft published October 4, 1999.</h3>
|
||||
<ul>
|
||||
<li>
|
||||
Changed the values used for some new
|
||||
<a href=ch4.sheader.html#sh_flags>section attribute flags</a>
|
||||
to accommodate platforms already using previously assigned values.
|
||||
<li>
|
||||
Added new section attribute flags
|
||||
<a href=ch4.sheader.html#shf_info_link><code>SHF_INFO_LINK</code></a>,
|
||||
<a href=ch4.sheader.html#shf_link_order><code>SHF_LINK_ORDER</code></a> and
|
||||
<a href=ch4.sheader.html#shf_os_nonconforming><code>SHF_OS_NONCONFORMING</code></a>
|
||||
<li>
|
||||
Added
|
||||
<a href=ch4.sheader.html#linking_rules>rules for linkers</a>
|
||||
when linking sections with unrecognized types or flags.
|
||||
</ul>
|
||||
<h3>Eighth draft published March 30, 2000.</h3>
|
||||
<ul>
|
||||
<li>
|
||||
Added the concept of <a href=ch4.sheader.html#section_groups>section
|
||||
groups</a>.
|
||||
<li>
|
||||
Removed the macros for <code>ELF32_ST_OTHER</code> and
|
||||
<code>ELF64_ST_OTHER</code>.
|
||||
</ul>
|
||||
<h3>Ninth draft published March 30, 2000.</h3>
|
||||
<ul>
|
||||
<li>
|
||||
Added <a href=ch4.symtab.html#protected_note>language</a>
|
||||
clarifying the semantics of symbols marked as <code>STV_PROTECTED</code>.
|
||||
<li>
|
||||
Added <a href=ch5.dynamic.html#pointer_note>language</a>
|
||||
clarifying the contents of the initialization and termination arrays.
|
||||
</ul>
|
||||
<h3>Tenth draft published 22 June 2000.</h3>
|
||||
<ul>
|
||||
<li>
|
||||
Added a <a href=ch4.symtab.html#protected_resolution>sentence</a>
|
||||
spelling out the behavior when resolving a symbol to a
|
||||
<code>STV_PROTECTED</code> definition from a shared object.
|
||||
<li>
|
||||
Added support for more than 65,000 sections in the
|
||||
<a href=ch4.eheader.html#many_sections>ELF header</a>,
|
||||
and with <code>SHT_SYMTAB_SHNDX</code> sections,
|
||||
and in <a href=ch4.symtab.html#many_sections>symbol tables</a>.
|
||||
</ul>
|
||||
<h3>Eleventh draft published 24 April 2001.</h3>
|
||||
<ul>
|
||||
<li>
|
||||
Updated <a href=ch4.eheader.html#e_machine>table</a>
|
||||
of <code>EM_*</code> entries.
|
||||
<li>
|
||||
<a href=ch4.sheader.html#section_group_flags>Added</a>
|
||||
<code>GRP_MASKOS</code> and <code>GRP_MASKPROC</code>.
|
||||
Changed section group description in a few ways,
|
||||
clarifying some fuzzy points and rewriting
|
||||
<a href=ch4.sheader.html#section_group_rules>the rules</a>
|
||||
for symbols referencing into section groups.
|
||||
<li>
|
||||
Changed the <a href=ch4.symtab.html#weak_note>warning</a> about using weak
|
||||
to be stronger.
|
||||
<li>
|
||||
<a href=ch4.eheader.html#osabi>Reworded</a>
|
||||
the <code>EI_OSABI</code> byte description
|
||||
to make is use clearer.
|
||||
<li>
|
||||
Added the <a href=ch4.eheader.html#generic_osabi_values>table</a>
|
||||
of now generic <code>EI_OSABI</code> values.
|
||||
<li>
|
||||
Added <a href=ch4.sheader.html#shf_tls><code>SHF_TLS</code></a>,
|
||||
<a href=ch5.pheader.html#pt_tls><code>PT_TLS</code></a>
|
||||
and its <a href=ch5.pheader.html#tls>contents</a>,
|
||||
<a href=ch5.dynamic.html#df_static_tls><code>DF_STATIC_TLS</code></a>,
|
||||
<a href=ch4.symtab.html#stt_tls><code>STT_TLS</code></a>,
|
||||
<a href=ch4.sheader.html#tbss><code>.tbss</code></a>, and
|
||||
<a href=ch4.sheader.html#tdata><code>.tdata</code></a>.
|
||||
<li>
|
||||
Changed
|
||||
<a href=ch4.symtab.html#many_sections>the rules</a> for
|
||||
<a href=ch4.sheader.html#many_sections><code>SHT_SYMTAB_SHNDX</code></a>
|
||||
contents to require <code>0</code> when the corresponding
|
||||
<code>st_shndx</code> field is not <code>SHN_XINDEX</code>.
|
||||
</ul>
|
||||
<hr>
|
||||
<a href="contents.html"><img src="contents.gif" alt="Contents"></a>
|
||||
<hr>
|
||||
<i>
|
||||
<small>
|
||||
© 1997, 1998, 1999, 2000, 2001 The Santa Cruz Operation, Inc. All rights reserved.
|
||||
</small>
|
||||
</i>
|
||||
</html>
|
||||
BIN
specs/sysv-abi-update.html/warning.gif
Normal file
BIN
specs/sysv-abi-update.html/warning.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 232 B |
Reference in New Issue
Block a user