|
|
A program to be loaded by the system must have at least one loadable segment (although this is not required by the file format). When the system creates loadable segments' memory images, it gives access permissions as specified in the p_flags member.
Name | Value | Meaning |
---|---|---|
PF_X | 0x1 | Execute |
PF_W | 0x2 | Write |
PF_R | 0x4 | Read |
PF_MASKOS | 0x0ff00000 | Unspecified |
PF_MASKPROC | 0xf0000000 | Unspecified |
Segment flag bits, p_flags
All bits included in the PF_MASKOS mask are reserved for operating system-specific semantics.
All bits included in the PF_MASKPROC mask are reserved for processor-specific semantics. If meanings are specified, the processor supplement explains them.
If a permission bit is 0, that type of access is denied. Actual memory permissions depend on the memory management unit, which may vary from one system to another. Although all flag combinations are valid, the system may grant more access than requested. In no case, however, will a segment have write permission unless it is specified explicitly. The following table shows both the exact flag interpretation and the allowable flag interpretation. ABI-conforming systems may provide either.
Flags | Value | Exact | Allowable |
---|---|---|---|
none | 0 | All access denied | All access denied |
PF_X | 1 | Execute only | Read, execute |
PF_W | 2 | Write only | Read, write, execute |
PF_W+PF_X | 3 | Write, execute | Read, write, execute |
PF_R | 4 | Read only | Read, execute |
PF_R+PF_X | 5 | Read, execute | Read, execute |
PF_R+PF_W | 6 | Read, write | Read, write, execute |
PF_R+PF_W+PF_X | 7 | Read, write, execute | Read, write, execute |
Segment permissions
For example, typical text segments have read and execute - but not write - permissions. Data segments normally have read, write, and execute permissions.
An object file segment comprises one or more sections, though this fact is transparent to the program header. Whether the file segment holds one or many sections also is immaterial to program loading. Nonetheless, various data must be present for program execution, dynamic linking, and so on. The diagrams below illustrate segment contents in general terms. The order and membership of sections within a segment may vary; moreover, processor-specific constraints may alter the examples below. See the processor supplement for details.
Text segments contain read-only instructions and data, typically including the following sections described earlier in ``Sections''. Other sections may also reside in loadable segments; these examples are not meant to give complete and exclusive segment contents.
.text |
.rodata |
.hash |
.dynsym |
.dynstr |
.plt |
.rel.got |
Text segment
Data segments contain writable data and instructions, typically including the following sections.
.data |
.dynamic |
.got |
.bss |
Data segment
A PT_DYNAMIC program header element points at the .dynamic section, explained in ``Dynamic section'' below. The .got and .plt sections also hold information related to position-independent code and dynamic linking. Although the .plt appears in a text segment in the previous table, it may reside in a text or a data segment, depending on the processor. See ``Global offset table'' and ``Procedure linkage table'' for more information.
As described in ``Sections'', the .bss section has the type SHT_NOBITS. Although it occupies no space in the file, it contributes to the segment's memory image. Normally, these uninitialized data reside at the end of the segment, thereby making p_memsz larger than p_filesz in the associated program header element.
Sometimes a vendor or system builder needs to mark an object file with special information that other programs will check for conformance, compatibility, and so on. Sections of type SHT_NOTE and program header elements of type PT_NOTE can be used for this purpose. The note information in sections and program header elements holds a variable amount of entries. In 64-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS64), each entry is an array of 8-byte words in the format of the target processor. In 32-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS32), each entry is an array of 4-byte words in the format of the target processor. Labels appear below to help explain note information organization, but they are not part of the specification.
namesz |
descsz |
type |
name |
[. . .] |
desc |
[. . .] |
Note information
+0 +1 +2 +3 +-------------------+ namesz | 7 | +-------------------+ descsz | 0 | No descriptor +-------------------+ type | 1 | +-------------------+ name | X | Y | Z | | | ---|----|----|----| | C | o | \0 | pad| +-------------------+ namesz | 7 | +-------------------+ descsz | 8 | +-------------------+ type | 3 | +-------------------+ name | X | Y | Z | | | ---|----|----|----| | c | o | \0 | pad| +-------------------+ desc | word 0 | +-------------------+ | word 1 | +-------------------+
Example note segment