Files
pintos_22/specs/sysv-abi-update.html/ch4.sheader.html
2024-10-01 23:37:39 +01:00

1308 lines
44 KiB
HTML

<html>
<title>Sections </title><p>
<h1>Sections</h1><p>
An object file's section header table lets one
locate all the file's sections.
The section header table is an array of <code>Elf32_Shdr</code>
or <code>Elf64_Shdr</code> structures
as described below.
A section header table index is a subscript into this array.
The ELF header's <code>e_shoff</code>
member gives the byte offset from the beginning of the
file to the section header table.
<code>e_shnum</code> normally tells how many entries the section header table contains.
<code>e_shentsize</code> gives the size in bytes of each entry.
<p>
If the number of sections is greater than or equal to
<code>SHN_LORESERVE</code> (<code>0xff00</code>), <code>e_shnum</code>
has the value <code>SHN_UNDEF</code> (<code>0</code>) and the
actual number of section header table
entries is contained in the <code>sh_size</code> field of
the section header at index <code>0</code>
(otherwise, the <code>sh_size</code> member of the initial entry
contains <code>0</code>).
<p>
Some section header table indexes are reserved in contexts
where index size is restricted, for example, the <code>st_shndx</code>
member of a symbol table entry and the <code>e_shnum</code> and
<code>e_shstrndx</code> members of the ELF header.
In such contexts, the reserved values do not represent actual
sections in the object file. Also in such contexts, an escape
value indicates that the actual section
index is to be found elsewhere, in a larger field.
<hr>
<b>Figure 4-7: Special Section Indexes</b>
<p>
<table border cellspacing=0>
<th><b>Name</b></th>
<th><b>Value</b></th>
<tr>
<td><code>SHN_UNDEF</code></td>
<td align=right><code>0</code></td>
</tr>
<tr>
<td><code>SHN_LORESERVE</code></td>
<td align=right><code>0xff00</code></td>
</tr>
<tr>
<td><code>SHN_LOPROC</code></td>
<td align=right><code>0xff00</code></td>
</tr>
<tr>
<td><code>SHN_HIPROC</code></td>
<td align=right><code>0xff1f</code></td>
</tr>
<tr>
<td><code>SHN_LOOS</code></td>
<td align=right><code>0xff20</code></td>
</tr>
<tr>
<td><code>SHN_HIOS</code></td>
<td align=right><code>0xff3f</code></td>
</tr>
<tr>
<td><code>SHN_ABS</code></td>
<td align=right><code>0xfff1</code></td>
</tr>
<tr>
<td><code>SHN_COMMON</code></td>
<td align=right><code>0xfff2</code></td>
</tr>
<tr>
<td><code>SHN_XINDEX</code></td>
<td align=right><code>0xffff</code></td>
</tr>
<tr>
<td><code>SHN_HIRESERVE</code></td>
<td align=right><code>0xffff</code></td>
</tr>
</table>
<hr>
<p>
<DL COMPACT>
<p><dt><code>SHN_UNDEF</code><dd>
This value marks an undefined, missing, irrelevant, or
otherwise meaningless section reference.
For example, a symbol ``defined'' relative to section number
<code>SHN_UNDEF</code> is an undefined symbol.
</dl>
<hr>
<img src=warning.gif alt="NOTE:">
Although index 0 is reserved as the undefined value,
the section header table contains an entry for index 0.
If the <code>e_shnum</code>
member of the ELF header says a file has 6 entries
in the section header table, they have the indexes 0 through 5.
The contents of the initial entry are specified later in this
section.
<hr><p>
<DL COMPACT>
<p><dt><code>SHN_LORESERVE</code><dd>
This value specifies the lower bound of the
range of reserved indexes.
<p><dt><code>SHN_LOPROC</code>&nbsp;through&nbsp;<code>SHN_HIPROC</code><dd>
Values in this inclusive range
are reserved for processor-specific semantics.
<p><dt><code>SHN_LOOS</code>&nbsp;through&nbsp;<code>SHN_HIOS</code><dd>
Values in this inclusive range
are reserved for operating system-specific semantics.
<p><dt><code>SHN_ABS</code><dd>
This value specifies absolute values for the corresponding reference.
For example, symbols defined relative to section number <code>SHN_ABS</code>
have absolute values and are not affected by relocation.
<p><dt><code>SHN_COMMON</code><dd>
Symbols defined relative to this section are common symbols,
such as FORTRAN
<code>COMMON</code>
or unallocated C external variables.
<p><dt><code>SHN_XINDEX</code><dd>
This value is an escape value.
It indicates that the actual section header index is too large to fit
in the containing field and is to be found in another location
(specific to the structure where it appears).
<p><dt><code>SHN_HIRESERVE</code><dd>
This value specifies the upper bound of the
range of reserved indexes.
The system reserves indexes between <code>SHN_LORESERVE</code>
and <code>SHN_HIRESERVE</code>,
inclusive; the values do not reference the section header table.
The section header table does not
contain entries for the reserved indexes.
</dl>
<p>
Sections contain all information in an object file
except the ELF header, the program header table,
and the section header table.
Moreover, object files' sections satisfy several conditions.
<ul>
<p><li>
Every section in an object file has exactly one
section header describing it.
Section headers may exist that do not have a section.
<p><li>
Each section occupies one contiguous (possibly empty)
sequence of bytes within a file.
<p><li>
Sections in a file may not overlap.
No byte in a file resides in more than one section.
<p><li>
An object file may have inactive space.
The various headers and the sections might not
``cover'' every byte in an object file.
The contents of the inactive data are unspecified.
</ul>
A section header has the following structure.
<hr>
<a name="section_header"></a>
<pre>
<b>Figure 4-8: Section Header</b>
<p>
<code>
typedef struct {
Elf32_Word sh_name;
Elf32_Word sh_type;
Elf32_Word sh_flags;
Elf32_Addr sh_addr;
Elf32_Off sh_offset;
Elf32_Word sh_size;
Elf32_Word sh_link;
Elf32_Word sh_info;
Elf32_Word sh_addralign;
Elf32_Word sh_entsize;
} Elf32_Shdr;
typedef struct {
Elf64_Word sh_name;
Elf64_Word sh_type;
Elf64_Xword sh_flags;
Elf64_Addr sh_addr;
Elf64_Off sh_offset;
Elf64_Xword sh_size;
Elf64_Word sh_link;
Elf64_Word sh_info;
Elf64_Xword sh_addralign;
Elf64_Xword sh_entsize;
} Elf64_Shdr;
</code>
</pre>
<hr>
<p>
<DL COMPACT>
<p><dt><code>sh_name</code><dd>
This member specifies the name of the section.
Its value is an index into the section header
string table section [see
<a href=ch4.strtab.html>``String Table''</a> below],
giving the location of a null-terminated string.
<p><dt><code>sh_type</code><dd>
This member categorizes the section's contents and semantics.
Section types and their descriptions appear
<a href="#sh_type">below</a>.
<p>
<p><dt><code>sh_flags</code><dd>
Sections support 1-bit flags that describe miscellaneous attributes.
Flag definitions appear
<a href=#sh_flags>below</a>.
<p>
<p><dt><code>sh_addr</code><dd>
If the section will appear in the memory image of a process,
this member gives the address at which the section's first
byte should reside.
Otherwise, the member contains 0.
<p><dt><code>sh_offset</code><dd>
This member's value gives the byte offset from the beginning of the file
to the first byte in the section.
One section type, <code>SHT_NOBITS</code>
described
<a href=#sh_type>below</a>,
occupies no space in the file, and its
<code>sh_offset</code> member locates the conceptual placement in the file.
<p><dt><code>sh_size</code><dd>
This member gives the section's size in bytes.
Unless the section type is
<code>SHT_NOBITS</code>, the section occupies <code>sh_size</code>
bytes in the file.
A section of type <code>SHT_NOBITS</code>
may have a non-zero size, but it occupies no space in the file.
<p><dt><code>sh_link</code><dd>
This member holds a section header table index link,
whose interpretation depends on the section type.
A <a href=#sh_link>table </a> below
describes the values.
<p><dt><code>sh_info</code><dd>
This member holds extra information,
whose interpretation depends on the section type.
A <a href=#sh_link>table</a> below
describes the values. If the <code>sh_flags</code> field for this
section header includes the attribute <a href=#shf_info_link><code>SHF_INFO_LINK</code></a>, then this member represents a section header table index.
<p><dt><code>sh_addralign</code><dd>
Some sections have address alignment constraints.
For example, if a section holds a doubleword,
the system must ensure doubleword alignment for the entire section.
The value of <code>sh_addr</code>
must be congruent to 0, modulo the value of <code>sh_addralign</code>.
Currently, only 0 and positive integral powers of two are allowed.
Values 0 and 1 mean the section has no alignment constraints.
<p><dt><code>sh_entsize</code><dd>
Some sections hold a table of fixed-size entries,
such as a symbol table.
For such a section, this member gives the size in bytes of each entry.
The member contains 0 if the section does not hold a table
of fixed-size entries.
</dl>
<p>
A section header's <code>sh_type</code> member specifies the section's semantics.
<hr>
<a name="sh_type"</a>
<b>Figure 4-9: Section Types,</b><code>sh_type</code></b>
<p>
<table border cellspacing=0>
<th><b>Name</b></th>
<th><b>Value</b></th>
<tr>
<td><code>SHT_NULL</code></td>
<td align=right><code>0</code></td>
</tr>
<tr>
<td><code>SHT_PROGBITS</code></td>
<td align=right><code>1</code></td>
</tr>
<tr>
<td><code>SHT_SYMTAB</code></td>
<td align=right><code>2</code></td>
</tr>
<tr>
<td><code>SHT_STRTAB</code></td>
<td align=right><code>3</code></td>
</tr>
<tr>
<td><code>SHT_RELA</code></td>
<td align=right><code>4</code></td>
</tr>
<tr>
<td><code>SHT_HASH</code></td>
<td align=right><code>5</code></td>
</tr>
<tr>
<td><code>SHT_DYNAMIC</code></td>
<td align=right><code>6</code></td>
</tr>
<tr>
<td><code>SHT_NOTE</code></td>
<td align=right><code>7</code></td>
</tr>
<tr>
<td><code>SHT_NOBITS</code></td>
<td align=right><code>8</code></td>
</tr>
<tr>
<td><code>SHT_REL</code></td>
<td align=right><code>9</code></td>
</tr>
<tr>
<td><code>SHT_SHLIB</code></td>
<td align=right><code>10</code></td>
</tr>
<tr>
<td><code>SHT_DYNSYM</code></td>
<td align=right><code>11</code></td>
</tr>
<tr>
<td><code>SHT_INIT_ARRAY</code></td>
<td align=right><code>14</code></td>
</tr>
<tr>
<td><code>SHT_FINI_ARRAY</code></td>
<td align=right><code>15</code></td>
</tr>
<tr>
<td><code>SHT_PREINIT_ARRAY</code></td>
<td align=right><code>16</code></td>
</tr>
<tr>
<td><code>SHT_GROUP</code></td>
<td align=right><code>17</code></td>
</tr>
<tr>
<td><code>SHT_SYMTAB_SHNDX</code></td>
<td align=right><code>18</code></td>
</tr>
<td><code>SHT_LOOS</code></td>
<td align=right><code>0x60000000</code></td>
</tr>
<tr>
<td><code>SHT_HIOS</code></td>
<td align=right><code>0x6fffffff</code></td>
</tr>
<tr>
<td><code>SHT_LOPROC</code></td>
<td align=right><code>0x70000000</code></td>
</tr>
<tr>
<td><code>SHT_HIPROC</code></td>
<td align=right><code>0x7fffffff</code></td>
</tr>
<tr>
<td><code>SHT_LOUSER</code></td>
<td align=right><code>0x80000000</code></td>
</tr>
<tr>
<td><code>SHT_HIUSER</code></td>
<td align=right><code>0xffffffff</code></td>
</tr>
</table>
<hr>
<p>
<DL COMPACT>
<p><dt><code>SHT_NULL</code><dd>
This value marks the section header as inactive;
it does not have an associated section.
Other members of the section header have undefined values.
<p><dt><code>SHT_PROGBITS</code><dd>
The section holds information defined by the program,
whose format and meaning are determined solely by the program.
<p><dt><code>SHT_SYMTAB</code>&nbsp;and&nbsp;<code>SHT_DYNSYM</code><dd>
These sections hold a symbol table.
Currently, an object file may have only one section of each type,
but this restriction may be relaxed in the future.
Typically, <code>SHT_SYMTAB</code>
provides symbols for link editing, though it may also be
used for dynamic linking.
As a complete symbol table, it may contain many symbols unnecessary
for dynamic linking.
Consequently, an object file may also contain a <code>SHT_DYNSYM</code>
section, which holds a minimal set of dynamic linking symbols,
to save space.
See <a href=ch4.symtab.html>``Symbol Table''</a> below
for details.
<p><dt><code>SHT_STRTAB</code><dd>
The section holds a string table.
An object file may have multiple string table sections.
See <a href=ch4.strtab.html>``String Table''</a>
below for details.
<p><dt><code>SHT_RELA</code><dd>
The section holds relocation entries
with explicit addends, such as type
<code>Elf32_Rela</code> for the 32-bit class of object files
or type <code>Elf64_Rela</code> for the 64-bit class of object files.
An object file may have multiple relocation sections.
<a href=ch4.reloc.html>``Relocation''</a>
below for details.
<p><dt><code>SHT_HASH</code><dd>
The section holds a symbol hash table.
Currently, an object file may have only one hash table,
but this restriction may be relaxed in the future.
See
<a href=ch5.dynamic.html#hash>``Hash Table''</a>
in the Chapter 5 for details.
<p><dt><code>SHT_DYNAMIC</code><dd>
The section holds information for dynamic linking.
Currently, an object file may have only one dynamic section,
but this restriction may be relaxed in the future.
See
<a href=ch5.dynamic.html#dynamic_section>``Dynamic Section''</a>
in Chapter 5 for details.
<p><dt><code>SHT_NOTE</code><dd>
The section holds information that marks the file in some way.
See
<a href=ch5.pheader.html#note_section>``Note Section''</a>
in Chapter 5 for details.
<p><dt><code>SHT_NOBITS</code><dd>
A section of this type occupies no space in the file but
otherwise resembles
<code>SHT_PROGBITS</code>.
Although this section contains no bytes, the <code>sh_offset</code>
member contains the conceptual file offset.
<p><dt><code>SHT_REL</code><dd>
The section holds relocation entries
without explicit addends, such as type
<code>Elf32_Rel</code> for the 32-bit class of object files or
type <code>Elf64_Rel</code> for the 64-bit class of object files.
An object file may have multiple relocation sections.
See <a href=ch4.reloc.html>``Relocation''</a>
below for details.
<p><dt><code>SHT_SHLIB</code><dd>
This section type is reserved but has unspecified semantics.
<a name=init_array></a>
<p><dt><code>SHT_INIT_ARRAY</code><dd>
This section contains an array of pointers to initialization functions,
as described in <a href=ch5.dynamic.html#init_fini>``Initialization and
Termination Functions''</a> in Chapter 5. Each pointer in the array
is taken as a parameterless procedure with a void return.
<p><dt><code>SHT_FINI_ARRAY</code><dd>
This section contains an array of pointers to termination functions,
as described in <a href=ch5.dynamic.html#init_fini>``Initialization and
Termination Functions''</a> in Chapter 5. Each pointer in the array
is taken as a parameterless procedure with a void return.
<p><dt><code>SHT_PREINIT_ARRAY</code><dd>
This section contains an array of pointers to functions that are
invoked before all other initialization functions,
as described in <a href=ch5.dynamic.html#init_fini>``Initialization and
Termination Functions''</a> in Chapter 5. Each pointer in the array
is taken as a parameterless procedure with a void return.
<p><dt><code>SHT_GROUP</code><dd>
This section defines a section group. A section group
is a set of sections that are related and that must be treated
specially by the linker (see <a href=#section_groups>below</a> for further
details). Sections of type <code>SHT_GROUP</code> may appear only
in relocatable objects (objects with the ELF header <code>e_type</code>
member set to <code>ET_REL</code>). The section header table entry
for a group section must appear in the section header table
before the entries for any of the sections that are members of
the group.
<p><dt><code>SHT_SYMTAB_SHNDX</code><dd>
<a name=many_sections></a>
This section is associated with a section of type <code>SHT_SYMTAB</code>
and is required if any of the section header indexes referenced
by that symbol table contain the escape value <code>SHN_XINDEX</code>.
The section is an array of <code>Elf32_Word</code> values.
Each value corresponds one to one with a symbol table entry
and appear in the same order as those entries.
The values represent the section header indexes against which
the symbol table entries are defined.
Only if corresponding symbol table entry's <code>st_shndx</code> field
contains the escape value <code>SHN_XINDEX</code>
will the matching <code>Elf32_Word</code> hold the actual section header index;
otherwise, the entry must be <code>SHN_UNDEF</code> (<code>0</code>).
<p><dt><code>SHT_LOOS</code>&nbsp;through&nbsp;<code>SHT_HIOS</code><dd>
Values in this inclusive range
are reserved for operating system-specific semantics.
<p><dt><code>SHT_LOPROC</code>&nbsp;through&nbsp;<code>SHT_HIPROC</code><dd>
Values in this inclusive range
are reserved for processor-specific semantics.
<p><dt><code>SHT_LOUSER</code><dd>
This value specifies the lower bound of the range of
indexes reserved for application programs.
<p><dt><code>SHT_HIUSER</code><dd>
This value specifies the upper bound of the range of
indexes reserved for application programs.
Section types between <code>SHT_LOUSER</code> and
<code>SHT_HIUSER</code> may be used by the application, without conflicting with
current or future system-defined section types.
</dl>
<p>
Other section type values are reserved.
As mentioned before, the section header for index 0 (<code>SHN_UNDEF</code>)
exists, even though the index marks undefined section references.
This entry holds the following.
<hr>
<b>Figure 4-10: Section Header 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>sh_name</code></td>
<td align=center><code>0</code></td>
<td>No name</td>
</tr>
<tr>
<td><code>sh_type</code></td>
<td align=center><code>SHT_NULL</code></td>
<td>Inactive</td>
</tr>
<tr>
<td><code>sh_flags</code></td>
<td align=center><code>0</code></td>
<td>No flags</td>
</tr>
<tr>
<td><code>sh_addr</code></td>
<td align=center><code>0</code></td>
<td>No address</td>
</tr>
<tr>
<td><code>sh_offset</code></td>
<td align=center><code>0</code></td>
<td>No offset</td>
</tr>
<tr>
<td><code>sh_size</code></td>
<td align=center>Unspecified</td>
<td>If non-zero, the actual number of section header entries</td>
</tr>
<tr>
<td><code>sh_link</code></td>
<td align=center>Unspecified</td>
<td>If non-zero, the index of the section header string table section</td>
</tr>
<tr>
<td><code>sh_info</code></td>
<td align=center><code>0</code></td>
<td>No auxiliary information</td>
</tr>
<tr>
<td><code>sh_addralign</code></td>
<td align=center><code>0</code></td>
<td>No alignment</td>
</tr>
<tr>
<td><code>sh_entsize</code></td>
<td align=center><code>0</code></td>
<td>No entries</td>
</tr>
</table>
<hr>
<p>
A section header's <code>sh_flags</code>
member holds 1-bit flags that describe the section's attributes.
Defined values appear in the following table;
other values are reserved.
<a name="sh_flags"</a>
<hr>
<b>Figure 4-11: Section Attribute Flags</b>
<p>
<table border cellspacing=0>
<th>Name</th>
<th>Value</th>
<tr>
<td><code>SHF_WRITE</code></td>
<td align=right><code>0x1</code></td>
</tr>
<tr>
<td><code>SHF_ALLOC</code></td>
<td align=right><code>0x2</code></td>
</tr>
<tr>
<td><code>SHF_EXECINSTR</code></td>
<td align=right><code>0x4</code></td>
</tr>
<tr>
<td><code>SHF_MERGE</code></td>
<td align=right><code>0x10</code></td>
</tr>
<tr>
<td><code>SHF_STRINGS</code></td>
<td align=right><code>0x20</code></td>
</tr>
<tr>
<td><code>SHF_INFO_LINK</code></td>
<td align=right><code>0x40</code></td>
</tr>
<tr>
<td><code>SHF_LINK_ORDER</code></td>
<td align=right><code>0x80</code></td>
</tr>
<tr>
<td><code>SHF_OS_NONCONFORMING</code></td>
<td align=right><code>0x100</code></td>
</tr>
<tr>
<td><code>SHF_GROUP</code></td>
<td align=right><code>0x200</code></td>
</tr>
<tr>
<td><code>SHF_TLS</code></td>
<td align=right><code>0x400</code></td>
</tr>
<tr>
<td><code>SHF_MASKOS</code></td>
<td align=right><code>0x0ff00000</code></td>
</tr>
<tr>
<td><code>SHF_MASKPROC</code></td>
<td align=right><code>0xf0000000</code></td>
</tr>
</table>
<hr>
<p>
If a flag bit is set in <code>sh_flags</code>,
the attribute is ``on'' for the section.
Otherwise, the attribute is ``off'' or does not apply.
Undefined attributes are set to zero.
<DL COMPACT>
<p><dt><code>SHF_WRITE</code><dd>
The section contains data that should be writable during
process execution.
<p><dt><code>SHF_ALLOC</code><dd>
The section occupies memory during process execution.
Some control sections do not reside in the memory image
of an object file; this attribute is off for those sections.
<p><dt><code>SHF_EXECINSTR</code><dd>
The section contains executable machine instructions.
<a name=shf_merge></a>
<p><dt><code>SHF_MERGE</code><dd>
The data in the section may be merged to eliminate duplication.
Unless the <code>SHF_STRINGS</code> flag is also set,
the data elements in the section are of a uniform size.
The size of each element is specified in the section
header's <code>sh_entsize</code> field.
If the <code>SHF_STRINGS</code> flag is also set,
the data elements consist of null-terminated character strings.
The size of each character is specified in the section
header's <code>sh_entsize</code> field.
<p>
Each element in the section is compared against other elements
in sections with the same name, type and flags.
Elements that would have identical values at program run-time
may be merged.
Relocations referencing elements of such sections must be
resolved to the merged locations of the referenced values.
Note that any relocatable values, including
values that would result in run-time relocations, must be
analyzed to determine whether the run-time values would actually
be identical. An ABI-conforming object file may not depend
on specific elements being merged, and an ABI-conforming
link editor may choose not to merge specific elements.
<a name=shf_strings></a>
<p><dt><code>SHF_STRINGS</code><dd>
The data elements in the section consist of null-terminated character
strings. The size of each character is specified in the section
header's <code>sh_entsize</code> field.
<a name=shf_info_link></a>
<p><dt><code>SHF_INFO_LINK</code><dd>
The <code>sh_info</code> field of this section header holds a section
header table index.
<a name=shf_link_order></a>
<p><dt><code>SHF_LINK_ORDER</code><dd>
This flag adds special ordering requirements for link editors.
The requirements apply if the
<code>sh_link</code> field of this section's header references
another section (the linked-to section).
If this section is combined with other
sections in the output file, it must appear in the same
relative order with respect to those sections, as the linked-to section
appears with respect to sections the linked-to section is combined with.
<p>
<hr>
<img src=warning.gif alt="NOTE:">
A typical use of this flag is to build a table that references text or
data sections in address order.
<hr>
<a name=shf_os_nonconforming></a>
<p><dt><code>SHF_OS_NONCONFORMING</code><dd>
This section requires special OS-specific processing
(beyond the standard <a href=#linking_rules>linking rules</a>)
to avoid incorrect behavior.
If this section has either an <code>sh_type</code> value
or contains <code>sh_flags</code> bits in the OS-specific ranges for
those fields, and a link editor processing this section does not
recognize those values, then the link editor should reject
the object file containing this section with an error.
<p><dt><code>SHF_GROUP</code><dd>
This section is a member (perhaps the only one) of a section group.
The section must be referenced by a section of type <code>SHT_GROUP</code>.
The <code>SHF_GROUP</code> flag may be set only for sections contained
in relocatable objects (objects with the ELF header <code>e_type</code>
member set to <code>ET_REL</code>).
See <a href=#section_groups>below</a> for further details.
<a name=shf_tls></a>
<p><dt><code>SHF_TLS</code><dd>
This section holds <i>Thread-Local Storage</i>,
meaning that each separate execution flow
has its own distinct instance of this data.
Implementations need not support this flag.
<p><dt><code>SHF_MASKOS</code><dd>
All bits included in this mask
are reserved for operating system-specific semantics.
<p><dt><code>SHF_MASKPROC</code><dd>
All bits included in this mask
are reserved for processor-specific semantics.
If meanings are specified, the processor supplement explains
them.
</dl>
<p>
Two members in the section header,
<code>sh_link</code> and <code>sh_info</code>,
hold special information, depending on section type.
<hr>
<a name="sh_link"></a>
<b>Figure 4-12:</b> <code>sh_link</code> <b>and</b> <code>sh_info</code> <b>Interpretation</b>
<p>
<table border cellspacing=0>
<th><code>sh_type</code></th>
<th><code>sh_link</code></th>
<th><code>sh_info</code></th>
<tr>
<td><code>SHT_DYNAMIC</code></td>
<td>The section header index of
the string table used by
entries in the section.</td>
<td><code>0</code></td>
</tr>
<tr>
<td><code>SHT_HASH</code></td>
<td>The section header index of
the symbol table to which
the hash table applies.</td>
<td><code>0</code></td>
</tr>
<tr>
<td><code>SHT_REL</code><br><code>SHT_RELA</code></td>
<td>The section header index of
the associated symbol table.</td>
<td>The section header index of
the section to which the
relocation applies.</td>
</tr>
<tr>
<td><code>SHT_SYMTAB</code><br><code>SHT_DYNSYM</code></td>
<td>The section header index of
the associated string table.</td>
<td>One greater than the symbol table index of the last local
symbol (binding <code>STB_LOCAL</code>).</td>
</tr>
<tr>
<td><code>SHT_GROUP</code></td>
<td>The section header index of
the associated symbol table.</td>
<td>The symbol table index of an entry in the
associated symbol table. The name of the specified symbol table
entry provides a signature for the section group.</td>
</tr>
<td><code>SHT_SYMTAB_SHNDX</code></td>
<td>The section header index of
the associated symbol table section.</td>
<td><code>0</code></td>
</tr>
<tr>
</table>
<hr>
<a name="linking_rules"></a>
<h2>Rules for Linking Unrecognized Sections</h2>
If a link editor encounters sections whose headers contain OS-specific
values it does not recognize in the <code>sh_type</code>
or <code>sh_flags</code> fields, the link editor should combine those
sections as described below.
<p>
If the section's <code>sh_flags</code> bits include the attribute
<code>SHF_OS_NONCONFORMING</code>, then the section requires
special knowledge to be correctly processed, and the link editor should
reject the object containing the section with an error.
<p>
Unrecognized sections that do not have the
<code>SHF_OS_NONCONFORMING</code> attribute, are combined in a two-phase
process. As the link editor combines sections using this process,
it must honor the alignment constraints of the
input sections (asserted by the <code>sh_addralign</code> field),
padding between sections with zero bytes, if necessary, and producing
a combination with the maximum alignment constraint of its
component input sections.
<p>
<ol>
<li>
In the first phase, input sections that match in name, type
and attribute flags should be concatenated into single sections.
The concatenation order should satisfy the requirements of
any known input section attributes (e.g, <code>SHF_MERGE</code>
and <code>SHF_LINK_ORDER</code>). When not otherwise constrained,
sections should be emitted in input order.
<li>
In the second phase, sections should be assigned to segments or
other units based on their attribute flags. Sections of each particular
unrecognized type should be assigned to the same unit unless
prevented by incompatible flags, and within a unit, sections
of the same unrecognized type should be placed together
if possible.
</ol>
<p>
Non OS-specific processing (e.g. relocation) should be applied
to unrecognized section types. An output section header table,
if present, should contain entries for unknown sections.
Any unrecognized section attribute flags should be removed.
<hr>
<img src=warning.gif alt="NOTE:">
It is recommended that link editors follow the same two-phase
ordering approach described above when linking sections of
known types. Padding between such sections may have values
different from zero, where appropriate.
<hr>
<a name="section_groups"></a>
<h2>Section Groups</h2>
Some sections occur in interrelated groups. For example, an out-of-line
definition of an inline function might require, in addition to the
section containing its executable instructions, a read-only data
section containing literals referenced, one or more debugging information
sections and other informational sections. Furthermore, there may be
internal references among these sections that would not make sense
if one of the sections were removed or replaced by a duplicate from
another object. Therefore, such groups must be
included or omitted from the linked object as a unit.
A section cannot be a member of more than one group.
<p>
A section of type <code>SHT_GROUP</code> defines such a grouping
of sections. The name of a symbol from one of the containing
object's symbol tables provides a signature for the section group.
The section header of the <code>SHT_GROUP</code> section specifies
the identifying symbol entry, as described above:
the <code>sh_link</code> member contains the section header index
of the symbol table section that contains the entry.
The <code>sh_info</code> member contains the symbol table index of
the identifying entry. The <code>sh_flags</code>
member of the section header contains <code>0</code>.
The name of the section (<code>sh_name</code>) is not specified.
<p>
The referenced signature symbol is not restricted.
Its containing symbol table section need not be a member of the group,
for example.
<p>
The section data of a <code>SHT_GROUP</code> section is an array
of <code>Elf32_Word</code> entries. The first entry is a flag word.
The remaining entries are a sequence of section header indices.
<p>
The following flags are currently defined:
<hr>
<a name="section_group_flags"></a>
<b>Figure 4-13: Section Group Flags</b>
<p>
<table border cellspacing=0>
<th>Name</th>
<th>Value</th>
<tr>
<td><code>GRP_COMDAT</code></td>
<td align=right><code>0x1</code></td>
</tr>
<tr>
<td><code>GRP_MASKOS</code></td>
<td align=right><code>0x0ff00000</code></td>
</tr>
<tr>
<td><code>GRP_MASKPROC</code></td>
<td align=right><code>0xf0000000</code></td>
</tr>
</table>
<hr>
<DL COMPACT>
<p><dt><code>GRP_COMDAT</code><dd>
This is a COMDAT group. It may duplicate another COMDAT group
in another object file, where duplication is defined as having the
same group signature. In such cases, only one of the
duplicate groups may be retained by the linker, and the
members of the remaining groups must be discarded.
<p><dt><code>GRP_MASKOS</code><dd>
All bits included in this mask
are reserved for operating system-specific semantics.
<p><dt><code>GRP_MASKPROC</code><dd>
All bits included in this mask
are reserved for processor-specific semantics.
If meanings are specified, the processor supplement explains
them.
</dl>
<p>
The section header indices in the <code>SHT_GROUP</code> section
identify the sections that make up the group. Each such section
must have the <code>SHF_GROUP</code> flag set in its <code>sh_flags</code>
section header member. If the linker decides to remove the section
group, it must remove all members of the group.
<hr>
<img src=warning.gif alt="NOTE:">
This requirement is not intended to imply that special case behavior
like removing debugging information requires removing the sections
to which that information refers, even if they are part of the same
group.
<hr>
<p>
<a name="section_group_rules"></a>
To facilitate removing a group without leaving dangling references
and with only minimal processing of the symbol table,
the following rules must be followed:
<ul>
<p><li>
A symbol table entry with <code>STB_GLOBAL</code> or <code>STB_WEAK</code>
binding that is defined relative to one of a group's sections,
and that is contained in a symbol table section
that is not part of the group,
must be converted to an undefined symbol
(its section index must be changed to <code>SHN_UNDEF</code>)
if the group members are discarded.
References to this symbol table entry from outside the group are allowed.
<p><li>
A symbol table entry with <code>STB_LOCAL</code> binding
that is defined relative to one of a group's sections,
and that is contained in a symbol table section
that is not part of the group,
must be discarded if the group members are discarded.
References to this symbol table entry from outside the group are not allowed.
<p><li>
An undefined symbol that is referenced only from one or more sections
that are part of a particular group,
and that is contained in a symbol table section
that is not part of the group,
is not removed when the group members are discarded.
In other words,
the undefined symbol is not removed
even if no references to that symbol remain.
<p><li>
There may not be non-symbol references to the sections comprising
a group from outside the group, for example, use of a group
member's section header index in an <code>sh_link</code> or
<code>sh_info</code> member.
</ul>
<a name="special_sections"></a>
<h2>Special Sections</h2>
Various sections hold program and control information.
<p>
The following table
shows sections that are used by the system
and have the indicated types and attributes.
<hr>
<b>Figure 4-14: Special Sections</b>
<p>
<table border cellspacing=0>
<th><b>Name</b></th>
<th><b>Type</b></th>
<th><b>Attributes</b></th>
<tr>
<td><code>.bss</code> </td>
<td><code>SHT_NOBITS</code> </td>
<td><code>SHF_ALLOC+SHF_WRITE</code> </td>
</tr>
<tr>
<td><code>.comment</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td>none</td>
</tr>
<tr>
<td><code>.data</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td><code>SHF_ALLOC+SHF_WRITE</code> </td>
</tr>
<tr>
<td><code>.data1</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td><code>SHF_ALLOC+SHF_WRITE</code> </td>
</tr>
<tr>
<td><code>.debug</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td>none</td>
</tr>
<tr>
<td><code>.dynamic</code> </td>
<td><code>SHT_DYNAMIC</code> </td>
<td>see below</td>
</tr>
<tr>
<td><code>.dynstr</code> </td>
<td><code>SHT_STRTAB</code> </td>
<td><code>SHF_ALLOC</code> </td>
</tr>
<tr>
<td><code>.dynsym</code> </td>
<td><code>SHT_DYNSYM</code> </td>
<td><code>SHF_ALLOC</code> </td>
</tr>
<tr>
<td><code>.fini</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td><code>SHF_ALLOC+SHF_EXECINSTR</code> </td>
</tr>
<tr>
<td><code>.fini_array</code> </td>
<td><code>SHT_FINI_ARRAY</code></td>
<td><code>SHF_ALLOC+SHF_WRITE</code> </td>
</tr>
<tr>
<td><code>.got</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td>see below</td>
</tr>
<tr>
<td><code>.hash</code> </td>
<td><code>SHT_HASH</code> </td>
<td><code>SHF_ALLOC</code> </td>
</tr>
<tr>
<td><code>.init</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td><code>SHF_ALLOC+SHF_EXECINSTR</code> </td>
</tr>
<tr>
<td><code>.init_array</code> </td>
<td><code>SHT_INIT_ARRAY</code></td>
<td><code>SHF_ALLOC+SHF_WRITE</code> </td>
</tr>
<tr>
<td><code>.interp</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td>see below</td>
</tr>
<tr>
<td><code>.line</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td>none</td>
</tr>
<tr>
<td><code>.note</code> </td>
<td><code>SHT_NOTE</code> </td>
<td>none</td>
</tr>
<tr>
<td><code>.plt</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td>see below</td>
</tr>
<tr>
<td><code>.preinit_array</code> </td>
<td><code>SHT_PREINIT_ARRAY</code></td>
<td><code>SHF_ALLOC+SHF_WRITE</code> </td>
</tr>
<tr>
<td><code>.rel</code><i>name</i> </td>
<td><code>SHT_REL</code> </td>
<td>see below</td>
</tr>
<tr>
<td><code>.rela</code><i>name</i> </td>
<td><code>SHT_RELA</code> </td>
<td>see below</td>
</tr>
<tr>
<td><code>.rodata</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td><code>SHF_ALLOC</code> </td>
</tr>
<tr>
<td><code>.rodata1</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td><code>SHF_ALLOC</code> </td>
</tr>
<tr>
<td><code>.shstrtab</code> </td>
<td><code>SHT_STRTAB</code> </td>
<td>none</td>
</tr>
<tr>
<td><code>.strtab</code> </td>
<td><code>SHT_STRTAB</code> </td>
<td>see below</td>
</tr>
<tr>
<td><code>.symtab</code> </td>
<td><code>SHT_SYMTAB</code> </td>
<td>see below</td>
</tr>
<tr>
<td><code>.symtab_shndx</code></td>
<td><code>SHT_SYMTAB_SHNDX</code> </td>
<td>see below</td>
</tr>
<tr>
<td><code>.tbss</code> </td>
<td><code>SHT_NOBITS</code></td>
<td><code>SHF_ALLOC+SHF_WRITE+SHF_TLS</code> </td>
</tr>
<tr>
<td><code>.tdata</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td><code>SHF_ALLOC+SHF_WRITE+SHF_TLS</code> </td>
</tr>
<tr>
<td><code>.tdata1</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td><code>SHF_ALLOC+SHF_WRITE+SHF_TLS</code> </td>
</tr>
<tr>
<td><code>.text</code> </td>
<td><code>SHT_PROGBITS</code></td>
<td><code>SHF_ALLOC+SHF_EXECINSTR</code> </td>
</tr>
</table>
<hr>
<p>
<dl>
<p><dt><code>.bss</code><dd>
This section holds uninitialized data that contribute
to the program's memory image.
By definition, the system initializes the data with zeros
when the program begins to run.
The section occupies no file space, as indicated by the section type,
<code>SHT_NOBITS</code>.
<p><dt><code>.comment</code><dd>
This section holds version control information.
<p><dt><code>.data</code>&nbsp;and&nbsp;<code>.data1</code><dd>
These sections hold initialized data that contribute
to the program's memory image.
<p><dt><code>.debug</code><dd>
This section holds information for symbolic debugging.
The contents are unspecified. All section names with the
prefix <code>.debug</code> are reserved for future use in the
ABI.
<p><dt><code>.dynamic</code><dd>
This section holds dynamic linking information.
The section's attributes will include the <code>SHF_ALLOC</code> bit.
Whether the <code>SHF_WRITE</code> bit is set is processor specific.
See Chapter 5 for more information.
<p><dt><code>.dynstr</code><dd>
This section holds strings needed for dynamic linking,
most commonly the strings
that represent the names associated with symbol table entries.
See Chapter 5 for more information.
<p><dt><code>.dynsym</code><dd>
This section holds the dynamic linking symbol table,
as described in
<a href=ch4.symtab.html>``Symbol Table''</a>.
See Chapter 5 for more information.
<p><dt><code>.fini</code><dd>
This section holds executable instructions that contribute
to the process termination code.
That is, when a program exits normally, the system arranges
to execute the code in this section.
<p><dt><code>.fini_array</code><dd>
This section holds an array of function pointers that contributes
to a single termination array for the executable or shared
object containing the section.
<p><dt><code>.got</code><dd>
This section holds the global offset table.
See ``Coding Examples'' in Chapter 3, ``Special Sections'' in
Chapter 4, and ``Global Offset Table'' in Chapter 5 of the
processor supplement for more information.
<p><dt><code>.hash</code><dd>
This section holds a symbol hash table.
See
<a href=ch5.dynamic.html#hash>``Hash Table''</a>
in Chapter 5 for more information.
<p><dt><code>.init</code><dd>
This section holds executable instructions that contribute
to the process initialization code.
When a program starts to run, the system arranges
to execute the code in this section before calling the
main program entry point (called <code>main</code> for C programs).
<p><dt><code>.init_array</code><dd>
This section holds an array of function pointers that contributes
to a single initialization array for the executable or shared
object containing the section.
<p><dt><code>.interp</code><dd>
This section holds the path name of a program interpreter.
If the file has a loadable segment that includes
relocation, the sections' attributes will include the
<code>SHF_ALLOC</code> bit; otherwise, that bit will be off.
See Chapter 5 for more information.
<p><dt><code>.line</code><dd>
This section holds line number information for symbolic
debugging, which describes
the correspondence between the source program and the
machine code.
The contents are unspecified.
<p><dt><code>.note</code><dd>
This section holds information in the format that
<a href=ch5.pheader.html#note_section>``Note Section''</a>.
in Chapter 5 describes.
<p><dt><code>.plt</code><dd>
This section holds the procedure linkage table.
See ``Special Sections'' in Chapter 4 and ``Procedure Linkage
Table'' in Chapter 5 of the processor supplement for more
information.
<p><dt><code>.preinit_array</code><dd>
This section holds an array of function pointers that contributes
to a single pre-initialization array for the executable or shared
object containing the section.
<p><dt><code>.rel</code><i>name</i>&nbsp;and&nbsp;<code>.rela</code><i>name</i><dd>
These sections hold relocation information, as described in
<a href=ch4.reloc.html>``Relocation''</a>.
If the file has a loadable segment that includes
relocation, the sections' attributes will include the
<code>SHF_ALLOC</code> bit; otherwise, that bit will be off.
Conventionally, <i>name</i>
is supplied by the section to which the relocations apply.
Thus a relocation section for <code>.text</code>
normally would have the name <code>.rel.text</code> or <code>.rela.text</code>.
<p><dt><code>.rodata</code>&nbsp;and&nbsp;<code>.rodata1</code><dd>
These sections hold read-only data that
typically contribute to a non-writable segment
in the process image.
See
<a href=ch5.pheader.html>``Program Header''</a>
in Chapter 5 for more information.
<p><dt><code>.shstrtab</code><dd>
This section holds section names.
<p><dt><code>.strtab</code><dd>
This section holds strings, most commonly the strings
that represent the names associated with symbol table entries.
If the file has a loadable segment that includes the
symbol string table, the section's attributes will include the
<code>SHF_ALLOC</code>
bit; otherwise, that bit will be off.
<p><dt><code>.symtab</code><dd>
This section holds a symbol table, as
<a href=ch4.symtab.html>``Symbol Table''</a>.
in this chapter describes.
If the file has a loadable segment that includes the
symbol table, the section's attributes will include the
<code>SHF_ALLOC</code> bit; otherwise, that bit will be off.
<p><dt><code>.symtab_shndx</code><dd>
This section holds the special symbol table section index
array, as described above. The section's attributes will include
the <code>SHF_ALLOC</code> bit if the associated symbol table
section does; otherwise that bit will be off.
<a name=tbss></a>
<p><dt><code>.tbss</code><dd>
This section holds uninitialized <i>thread-local data</i> that contribute
to the program's memory image.
By definition,
the system initializes the data with zeros
when the data is instantiated for each new execution flow.
The section occupies no file space, as indicated by the section type,
<code>SHT_NOBITS</code>.
Implementations need not support thread-local storage.
<a name=tdata></a>
<p><dt><code>.tdata</code><dd>
This section holds initialized <i>thread-local data</i> that contributes
to the program's memory image.
A copy of its contents is instantiated by the system
for each new execution flow.
Implementations need not support thread-local storage.
<p><dt><code>.text</code><dd>
This section holds the ``text,'' or executable
instructions, of a program.
</dl>
<p>
Section names with a dot (<code>.</code>) prefix
are reserved for the system,
although applications may use these sections
if their existing meanings are satisfactory.
Applications may use names without the prefix to
avoid conflicts with system sections.
The object file format lets one define sections not
shown in the previous list.
An object file may have more than one section
with the same name.
<p>
Section names reserved for a processor architecture
are formed by placing an abbreviation of the architecture
name ahead of the section name.
The name should be taken from the
architecture names used for <code>e_machine</code>.
For instance <code>.</code>FOO<code>.psect</code> is the <code>psect</code>
section defined by the FOO architecture.
Existing extensions are called by their historical names.
<p>
<table>
<caption><b>Pre-existing Extensions</b></caption>
<tr>
<td><code>.sdata</code></td>
<td><code>.tdesc</code></td>
</tr>
<tr>
<td><code>.sbss</code></td>
<td><code>.lit4</code></td>
</tr>
<tr>
<td><code>.lit8</code></td>
<td><code>.reginfo</code></td>
</tr>
<tr>
<td><code>.gptab</code></td>
<td><code>.liblist</code></td>
</tr>
<tr>
<td><code>.conflict</code></td>
</tr>
</table>
<hr>
<img src=warning.gif alt="NOTE:">
For information on processor-specific sections,
see the ABI supplement for the desired processor.
<hr>
<a href=ch4.eheader.html><img src=previous.gif alt="Previous"></a>
<a href=contents.html><img src=contents.gif alt="Contents"></a>
<a href=ch4.strtab.html><img src=next.gif alt="Next"></a>
<hr>
<i>
<small>
&#169; 1997, 1998, 1999, 2000, 2001 The Santa Cruz Operation, Inc. All rights reserved.
</small>
</i>
</html>