provided code
This commit is contained in:
LabTS
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>
|
||||
Reference in New Issue
Block a user