The elements of this structure are:

vn_version

This member identifies the version of the structure itself, as listed in the following table.

Table 7-33 ELF Version Dependency Structure Versions

Name	Value	Meaning
VER_NEED_NONE	0	Invalid version.
VER_NEED_CURRENT	>=1	Current version.

The value 1 signifies the original section format. Extensions will create new versions with higher numbers. The value of VER_NEED_CURRENT changes as necessary to reflect the current version number.

vn_cnt

The number of elements in the Elf32_Vernaux array.

vn_file

The string table offset to a null-terminated string, that provides the file name having a version dependency. This name matches one of the .dynamic dependencies found in the file. See Dynamic Section.

vn_aux

The byte offset, from the start of this Elf32_Verneed entry, to the Elf32_Vernaux array of version definitions required from the associated file dependency. There must exist at least one version dependency. Additional version dependencies can be present, the number being indicated by the vn_cnt value.

vn_next

The byte offset, from the start of this Elf32_Verneed entry, to the next Elf32_Verneed entry.

vna_hash

The hash value of the version dependency name. This value is generated using the same hashing function described in Hash Table Section.

vna_flags

Version dependency specific information, as listed in the following table.

Table 7-34 ELF Version Dependency Structure Flags

Name	Value	Meaning
VER_FLG_WEAK	0x2	Weak version identifier.

A weak version dependency indicates an original binding to a weak version definition.

vna_other

Presently unused.

vna_name

The string table offset to a null-terminated string, giving the name of the version dependency.

vna_next

The byte offset from the start of this Elf32_Vernaux entry to the next Elf32_Vernaux entry.

Dynamic Linking

This section describes the object file information and system actions that create running programs. Most information here applies to all systems. Information specific to one processor resides in sections marked accordingly.

Executable and shared object files statically represent application programs. To execute such programs, the system uses the files to create dynamic program representations, or process images. A process image has segments that contain its text, data, stack, and so on. The major subsections of this section are:

• Program Header describes object file structures that are directly involved in program execution. The primary data structure, a program header table, locates segment images in the file and contains other information needed to create the memory image of the program.

• Program Loading (Processor-Specific) describes the information used to load a program into memory.

• Runtime Linker describes the information used to specify and resolve symbolic references among the object files of the process image.

Program Header

An executable or shared object file's program header table is an array of structures, each describing a segment or other information that the system needs to prepare the program for execution. An object file segment contains one or more sections, as described in Segment Contents.

Program headers are meaningful only for executable and shared object files. A file specifies its own program header size with the ELF header's e_phentsize and e_phnum members..

A program header has the following structure, defined in sys/elf.h:

typedef struct {
        Elf32_Word      p_type;
        Elf32_Off       p_offset;
        Elf32_Addr      p_vaddr;
        Elf32_Addr      p_paddr;
        Elf32_Word      p_filesz;
        Elf32_Word      p_memsz;
        Elf32_Word      p_flags;
        Elf32_Word      p_align;
} Elf32_Phdr;

typedef struct {
        Elf64_Word      p_type;
        Elf64_Word      p_flags;
        Elf64_Off       p_offset;
        Elf64_Addr      p_vaddr;
        Elf64_Addr      p_paddr;
        Elf64_Xword     p_filesz;
        Elf64_Xword     p_memsz;
        Elf64_Xword     p_align;
} Elf64_Phdr;

The elements of this structure are:

p_type

The kind of segment this array element describes or how to interpret the array element's information. Type values and their meanings are specified in Table 7-35.

p_offset

The offset from the beginning of the file at which the first byte of the segment resides.

p_vaddr

The virtual address at which the first byte of the segment resides in memory.

p_paddr

The segment's physical address for systems in which physical addressing is relevant. Because the system ignores physical addressing for application programs, this member has unspecified contents for executable files and shared objects.

p_filesz

The number of bytes in the file image of the segment, which can be zero.

p_memsz

The number of bytes in the memory image of the segment, which can be zero.

p_flags

Flags relevant to the segment. Type values and their meanings are specified in Table 7-36.

p_align

Loadable process segments must have congruent values for p_vaddr and p_offset, modulo the page size. This member gives the value to which the segments are aligned in memory and in the file. Values 0 and 1 mean no alignment is required. Otherwise, p_align should be a positive, integral power of 2, and p_vaddr should equal p_offset, modulo p_align. See Program Loading (Processor-Specific).

Some entries describe process segments. Other entries give supplementary information and do not contribute to the process image. Segment entries can appear in any order, except as explicitly noted. Defined type values are listed in the following table.

Table 7-35 ELF Segment Types