Object files

Segment permissions

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

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

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.

Segment contents

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.

Note section

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

namesz
and name: The first namesz bytes in name contain a null-terminated character representation of the entry's owner or originator. There is no formal mechanism for avoiding name conflicts. By convention, vendors use their own name, such as XYZ Computer Company, as the identifier. If no name is present, namesz contains 0. Padding is present, if necessary, to ensure 8 or 4-byte alignment for the descriptor (depending on whether the file is a 64-bit or 32-bit object). Such padding is not included in namesz.
descsz
and desc: The first descsz bytes in desc hold the note descriptor. The ABI places no constraints on a descriptor's contents. If no descriptor is present, descsz contains 0. Padding is present, if necessary, to ensure 8 or 4-byte alignment for the next note entry (depending on whether the file is a 64-bit or 32-bit object). Such padding is not included in descsz.
type: This word gives the interpretation of the descriptor. Each originator controls its own types; multiple interpretations of a single value may exist. Thus, a program must recognize both the name and the type to recognize a descriptor. Types currently must be non-negative. The ABI does not define what descriptors mean.

To illustrate, the following note segment holds two entries.

                           +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

NOTE: The system reserves note information with no name (namesz==0) and with a zero-length name (name[0]=='\0') but currently defines no types. All other names must have at least one non-null character.

NOTE: Note information is optional. The presence of note information does not affect a program's ABI conformance, provided the information does not affect the program's execution behavior. Otherwise, the program does not conform to the ABI and has undefined behavior.