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 the HDR_NOALLOC mapfile directive.
data

The data segment defines a writable loadable segment. The data 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 the PLT 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 type SHT_NOTE. The link-editor provides a PT_NOTE program header entry to reference the note 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 the SHF_AMD64_LARGE must be placed in an output segment that does not exceed 2 Gbytes in size. The lrodata and ldata predefined segments are present for x86–64 output objects only, and are used to handle sections with the SHF_AMD64_LARGE flag set. lrodata receives read-only sections, and ldata 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 entry p_filesz and p_memsz fields, which must follow the following rule.
```
        p_memsz >= p_filesz
```
If p_memsz is greater than p_filesz, the extra bytes are NOBITS. The first p_filesz bytes come from the object file, and any remaining bytes up to p_memsz are zeroed by the system prior to use.

The default assignment rules assign read-only NOBITS sections to the text segment, and writable NOBITS sections to the data segment. The link-editor defines the bss segment as an alternative segment that can accept writable NOBITS 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 separate bss 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 if bss is enabled, bss becomes the final segment. When building a dynamic executable, enabling the bss segment with an appropriate alignment can be used to enable large page assignment of the heap. For example, the following enables the bss 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.