Predefined Segments
The link-editor provides a predefined set of output segment descriptors and entrance criteria. These definitions satisfy the needs of most linking scenarios, and comply with the ELF layout rules and conventions expected by the system.
The text, data, and extra segments are of primary interest, while the others serve more specialized purposes, as described below.
-
text
The
text
segment defines a read-only executable loadable segment that accepts allocable, non-writable sections. This includes executable code, read-only data needed by the program, and read-only data produced by the link-editor for use by the runtime linker such as the dynamic symbol table.The
text
segment is the first segment in the process, and is therefore assigned the ELF header, and the program header array by the link-editor. This can be prevented using theHDR_NOALLOC
mapfile
directive. -
data
The
data
segment defines a writable loadable segment. Thedata
segment is used for writable data needed by the program, and for writable data used by the runtime linker, such as the Global Offset Table (GOT
), and the Procedure Linkage Table (PLT
), on architectures such as SPARC that require thePLT
sections to be writable. -
extra
The extra segment captures all sections not assigned elsewhere, directed there by the final entrance criterion record. Common examples are the full symbol table (
.symtab
), and the various sections produced for the benefit of debuggers. This is a null segment, and has no corresponding program header table entry. -
note
The
note
segment captures all sections of typeSHT_NOTE
. The link-editor provides aPT_NOTE
program header entry to reference thenote
segment. -
lrodata
/ldata
The x86–64 ABI defines small, medium, and large compilation models. The ABI requires sections for the medium and large models to set the
SHF_AMD64_LARGE
section flag. An input section lacking theSHF_AMD64_LARGE
must be placed in an output segment that does not exceed 2 Gbytes in size. Thelrodata
andldata
predefined segments are present for x86–64 output objects only, and are used to handle sections with theSHF_AMD64_LARGE
flag set.lrodata
receives read-only sections, andldata
receives the others. -
bss
ELF allows for any segment to contain
NOBITS
sections. The link-editor places such sections at the end of the segment they are assigned to. This is implemented using the program header entryp_filesz
andp_memsz
fields, which must follow the following rule.p_memsz >= p_filesz
If
p_memsz
is greater thanp_filesz
, the extra bytes areNOBITS
. The firstp_filesz
bytes come from the object file, and any remaining bytes up top_memsz
are zeroed by the system prior to use.The default assignment rules assign read-only
NOBITS
sections to the text segment, and writableNOBITS
sections to the data segment. The link-editor defines thebss
segment as an alternative segment that can accept writableNOBITS
sections. This segment is disabled by default, and must be explicitly enabled to be used.Since writable
NOBITS
sections are easily handled as part of the data segment, the benefit of having a separatebss
segment may not be immediately obvious. By convention, the process dynamic memory heap starts at the end of the final segment, which must be writable. This is usually the data segment, but ifbss
is enabled,bss
becomes the final segment. When building a dynamic executable, enabling thebss
segment with an appropriate alignment can be used to enable large page assignment of the heap. For example, the following enables thebss
segment and sets an alignment of 4 Mbytes.LOAD_SEGMENT bss { ALIGN=0x400000; };
Note:
Users are cautioned that an alignment specification can be machine-specific, and may not have the same benefit on different hardware platforms. A more flexible means of requesting the most optimal underlying page size may evolve in future releases.