Special Sections
Various sections hold program and control information. Sections in the following table are used by the system and have the indicated types and attributes.
Table 14-12 ELF Special Sections
| Name | Type | Attribute |
|---|---|---|
|
|
|
|
|
|
|
None |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
None |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
None |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
None |
|
|
|
Refer to the explanation following this table. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
None |
|
|
|
None |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
None |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
None |
|
|
|
None |
|
|
|
None |
|
|
|
|
-
.bss -
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
SHT_NOBITS. -
.comment -
Comment information, typically contributed by the components of the compilation system. This section can be manipulated by
mcs(1). -
.data,.data1 -
Initialized data that contribute to the program's memory image.
-
.dynamic -
Dynamic linking information. See Dynamic Section for details.
-
.dynstr -
Strings needed for dynamic linking, most commonly the strings that represent the names associated with symbol table entries.
-
.dynsym -
Dynamic linking symbol table. See Symbol Table Section for details.
-
.eh_frame_hdr,.eh_frame -
Call frame information used to unwind the stack.
-
.fini -
Executable instructions that contribute to a single termination function for the dynamic object containing the section. See Initialization and Termination Routines for details.
-
.fini_array -
An array of function pointers that contribute to a single termination array for the dynamic object containing the section. See Initialization and Termination Routines for details.
-
.got -
The global offset table. See Global Offset Table (Processor-Specific) for details.
-
.hash -
Symbol hash table. See Hash Table Section for details.
-
.init -
Executable instructions that contribute to a single initialization function for the dynamic object containing the section. See Initialization and Termination Routines for details.
-
.init_array -
An array of function pointers that contributes to a single initialization array for the dynamic object containing the section. See Initialization and Termination Routines for details.
-
.interp -
The path name of a program interpreter. See Program Interpreter for details.
-
.lbss -
x64 specific uninitialized data. This data is similar to
.bss, but provides for a section that is larger than 2 Gbytes. -
.ldata,.ldata1 -
x64 specific initialized data. This data is similar to
.data, but provides for a section that is larger than 2 Gbytes. -
.lrodata,.lrodata1 -
x64 specific read-only data. This data is similar to
.rodata, but provides for a section that is larger than 2 Gbytes. -
.note -
Information in the format described in Note Section.
-
.plt -
The procedure linkage table. See Procedure Linkage Table (Processor-Specific) for details.
-
.preinit_array -
An array of function pointers that contribute to a single pre-initialization array for the executable containing the section. See Initialization and Termination Routines for details.
-
.rela -
Relocations that do not apply to a particular section. One use of this section is for register relocations. See Register Symbols for details.
-
.relname,.relaname -
Relocation information, as Relocation Sections describes. If the file has a loadable segment that includes relocation, the sections' attributes include the
SHF_ALLOCbit. Otherwise, that bit is off. Conventionally, name is supplied by the section to which the relocations apply. Thus, a relocation section for.textnormally will have the name.rel.textor.rela.text. -
.rodata,.rodata1 -
Read-only data that typically contribute to a non-writable segment in the process image. See Program Header for details.
-
.shstrtab -
Section names.
-
.strtab -
Strings, most commonly the strings that represent the names that are associated with symbol table entries. If the file has a loadable segment that includes the symbol string table, the section's attributes include the
SHF_ALLOCbit. Otherwise, that bit is turned off. -
.symtab -
Symbol table, as Symbol Table Section describes. If the file has a loadable segment that includes the symbol table, the section's attributes include the
SHF_ALLOCbit. Otherwise, that bit is turned off. -
.symtab_shndx -
This section holds the special symbol table section index array, as described by
.symtab. The section's attributes include theSHF_ALLOCbit if the associated symbol table section does. Otherwise, that bit is turned off. -
.tbss -
This section holds uninitialized thread-local data 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,
SHT_NOBITS. See Thread-Local Storage for details. -
.tdata,.tdata1 -
These sections hold initialized thread-local data that contribute to the program's memory image. A copy of its contents is instantiated by the system for each new execution flow. See Thread-Local Storage for details.
-
.text -
The text or executable instructions of a program.
-
.SUNW_ancillary -
Ancillary group information. See Ancillary Section for details.
-
.SUNW_ancillary_strtab -
Strings associated with the
.SUNW_ancillarysection. -
.SUNW_bss -
Partially initialized data for shared objects that contribute to the program's memory image. The data is initialized at runtime. The section occupies no file space, as indicated by the section type
SHT_NOBITS. -
.SUNW_cap -
Capability requirements. See Capabilities Section for details.
-
.SUNW_capchain -
Capability chain table. See Capabilities Section for details.
-
.SUNW_capinfo -
Capability symbol information. See Capabilities Section for details.
-
.SUNW_ctf -
Identifies CTF (Compact C Type Format) debugging information. CTF data is consumed by Oracle Solaris observability tools such as
mdband DTrace. See themdb(1) anddtrace(8) man pages. -
.SUNW_heap -
The heap of a dynamic executable created from
dldump(3C). -
.SUNW_dynsymsort -
An array of indices to symbols in the combined
.SUNW_ldynsym–.dynsymsymbol table. The indices are sorted to reference symbols in order of increasing address. Symbols that do not represent variables or do not represent functions are not included. In the case of redundant global symbols and weak symbols, only the weak symbol is kept. See Symbol Sort Sections for details. -
.SUNW_dynsymnsort -
An array of indices to symbols in the combined
.SUNW_ldynsym–.dynsymsymbol table. The indices are sorted to reference symbols by name, in increasing lexical order. Symbols that do not represent variables or do not represent functions are not included. See Symbol Sort Sections for details. -
.SUNW_dyntlssort -
An array of indices to thread-local storage symbols in the combined
.SUNW_ldynsym–.dynsymsymbol table. The indices are sorted to reference symbols in order of increasing offset. Symbols that do not represent TLS variables are not included. In the case of redundant global symbols and weak symbols, only the weak symbol is kept. See Symbol Sort Sections for details. -
.SUNW_ldynsym -
Augments the
.dynsymsection. This section contains local function symbols, for use in contexts where the full.symtabsection is not available. The link-editor always places the data for a.SUNW_ldynsymsection immediately before, and adjacent to, the.dynsymsection. Both sections always use the same.dynstrstring table section. This placement and organization, allows both symbol tables to be treated as a single larger symbol table. See Symbol Table Section. -
.SUNW_move -
Additional information for partially initialized data. See Move Section for details.
-
.SUNW_phname -
Program header names. See Program Header Name Section for details.
-
.SUNW_reloc -
Relocation information, as Relocation Sections describes. This section is a concatenation of relocation sections that provides better locality of reference of the individual relocation records. Only the offset of the relocation record is meaningful, thus the section
sh_infovalue is zero. -
.SUNW_syminfo -
Additional symbol table information. See Syminfo Table Section for details.
-
.SUNW_symtabsort -
An array of indices to symbols in the
.symtabsymbol table. The indices are sorted to reference symbols in order of increasing address. Symbols that do not represent variables or do not represent functions are not included. In the case of redundant global symbols and weak symbols, only the weak symbol is kept. See Symbol Sort Sections for details. -
.SUNW_symtabnsort -
An array of indices to symbols in the
.symtabsymbol table. The indices are sorted to reference symbols by name, in increasing lexical order. Symbols that do not represent variables or do not represent functions are not included. See Symbol Sort Sections for details. -
.SUNW_symtlssort -
An array of indices to thread-local storage symbols in the
.symtabsymbol table. The indices are sorted to reference symbols in order of increasing offset. Symbols that do not represent TLS variables are not included. In the case of redundant global symbols and weak symbols, only the weak symbol is kept. See Symbol Sort Sections for details. -
.SUNW_version -
Versioning information. See Versioning Sections for details.
Section names with a dot (.) prefix are reserved for the system, although applications can use these sections if their existing meanings are satisfactory. Applications can use names without the prefix to avoid conflicts with system sections. The object file format enables you to define sections that are not reserved. An object file can have more than one section with the same name.
Section names that are 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 that are used for e_machine. For example,
.Foo.psect is the psect section defined by the
FOO architecture.
Existing extensions use their historical names.