A section is the smallest unit of an object that can be relocated. Use the elfdump(1) command to inspect the components of an object or executable file generated by the assembler.
The following sections are commonly present in an ELF file:
Read-write uninitialized data (section header only)
These sections contain all other information in an object file and satisfy several conditions.
Every section must have one section header describing the section. However, a section header does not need to be followed by a section.
Each section occupies one contiguous sequence of bytes within a file. The section may be empty (that is, of zero-length).
A byte in a file can reside in only one section. Sections in a file cannot overlap.
An object file may have inactive space. The contents of the data in the inactive space are unspecified.
The section header allows you to locate all of the file sections. An entry in a section header table contains information characterizing the data in a section.
The section header contains a number of fields as described in detail in sys/elf.h and Section Headers in Oracle Solaris 11.3 Linkers and Libraries Guide . However, only the following fields are of immediate interest to the assembly language programmer because they can be specified in assembler pseudo-operations (directives):
Description: One-bit descriptions of section attributes. Figure 7, Table 7, Section Attribute Flags describes the some of the section attribute flags. For details and additional flags, see Section Headers in Oracle Solaris 11.3 Linkers and Libraries Guide
Description: Extra information. The interpretation of this information depends on the section type, as described in . Figure 8, Table 8, Section Types Modified by Assembler Pseudo-ops
Description: Section header table index link. The interpretation of this information depends on the section type, as described in . Figure 8, Table 8, Section Types Modified by Assembler Pseudo-ops
A section that can be manipulated by the section control directives is known as a user section. You can use the section control directives to change the user section in which code or data is generated. Figure 9, Table 9, User Sections In Section Control Directives lists some of the predefined user sections that can be named in the section control directives. For details and additional information, see Special Sections in Oracle Solaris 11.3 Linkers and Libraries Guide.
The .init sections contain codes that are to be executed before the the main program is executed. To create an .init section in an object file, use the assembler pseudo-ops shown in Example 1, Creating an .init Section.Example 1 Creating an .init Section
.section ".init" .align 4 <instructions>
At link time, the .init sections in a sequence of .o files are concatenated into an .init section in the linker output file. The code in the .init section are executed before the main program is executed.
Because the whole .init section is treated as a single function body, it is recommented that the only code added to these sections be in the following form:.
The called routine should be located in another section. This will prevent conflicting register and stack usage within the .init sections.
.fini sections contain codes that are to be executed after the the main program is executed. To create an .fini section in an object file, use the assembler pseudo-ops shown in Example 2, Creating an .fini Section.Example 2 Creating an .fini Section
.section ".fini" .align 4 <instructions>
At link time, the .fini sections in a sequence of .o files are concatenated into a .fini section in the linker output file. The codes in the .fini section are executed after the main program is executed.
Because the whole .fini section is treated as a single function body, it is recommended that the only code added to these section be in the following form:
call routine_name nop
The called routine should be located in another section. This will prevent conflicting register and stack usage within the .fini sections.
Figure 10, Table 10, Reserved Sections lists sections that are predefined and not under user control. Therefore, these section names are reserved by the assembler and should be avoided.
A symbol table contains information to locate and relocate symbolic definitions and references. The Oracle Solaris SPARC assembler creates a symbol table section for the object file. It makes an entry in the symbol table for each symbol that is defined or referenced in the input file and is needed during linking. The symbol table is then used by the Oracle Solaris linker during relocation. The section header contains the symbol table index for the first non-local symbol.
A symbol table contains the following information defined by Elf32_Sym and Elf64_Sym in sys/elf.h and Symbol Table Section in Oracle Solaris 11.3 Linkers and Libraries Guide:
Description: Index into the object file symbol string table. A value of zero indicates the symbol table entry has no name; otherwise, the value represents the string table index that gives the symbol name.
Description: Specifies the symbol type and binding attributes. Figure 11, Table 11, Symbol Type Attributes ELF32_ST_TYPE and ELF64_ST_TYPE and Figure 12, Table 12, Symbol Binding Attributes ELF32_ST_BIND and ELF64_ST_BIND describe these values.
Description: Contains the section header table index to another relevant section, if specified. As a section moves during relocation, references to the symbol will continue to point to the same location because the value of the symbol will change as well.
Figure 12, Table 12, Symbol Binding Attributes ELF32_ST_BIND and ELF64_ST_BIND shows the symbol binding attributes.
A string table is a section which contains null-terminated variable-length character sequences, or strings, in the object file; for example, symbol names and file names. The strings are referenced in the section header as indexes into the string table section.
A string table index may refer to any byte in the section.
Empty string table sections are permitted; however, the index referencing this section must contain zero.