JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 11.1 Linkers and Libraries Guide     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

Part I Using the Link-Editor and Runtime Linker

1.  Introduction to the Oracle Solaris Link Editors

2.  Link-Editor

3.  Runtime Linker

4.  Shared Objects

Part II Quick Reference

5.  Link-Editor Quick Reference

Part III Advanced Topics

6.  Direct Bindings

7.  Building Objects to Optimize System Performance

8.  Mapfiles

9.  Interfaces and Versioning

10.  Establishing Dependencies with Dynamic String Tokens

11.  Extensibility Mechanisms

Part IV ELF Application Binary Interface

12.  Object File Format

13.  Program Loading and Dynamic Linking

Program Header

Base Address

Segment Permissions

Segment Contents

Program Loading (Processor-Specific)

Program Interpreter

Runtime Linker

Dynamic Section

Global Offset Table (Processor-Specific)

Procedure Linkage Table (Processor-Specific)

32-bit SPARC: Procedure Linkage Table

64-bit SPARC: Procedure Linkage Table

32-bit x86: Procedure Linkage Table

x64: Procedure Linkage Table

14.  Thread-Local Storage

Part V Appendices

A.  Linker and Libraries Updates and New Features

B.  System V Release 4 (Version 1) Mapfiles

Index

Program Header

An executable or shared object file's program header table is an array of structures. Each structure describes 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. See 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;
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 13-1.

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 that are relevant to the segment. Type values and their meanings are specified in Table 13-2.

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 13-1 ELF Segment Types

Name
Value
PT_NULL
0
PT_LOAD
1
PT_DYNAMIC
2
PT_INTERP
3
PT_NOTE
4
PT_SHLIB
5
PT_PHDR
6
PT_TLS
7
PT_LOOS
0x60000000
PT_SUNW_UNWIND
0x6464e550
PT_SUNW_EH_FRAME
0x6474e550
PT_LOSUNW
0x6ffffffa
PT_SUNWBSS
0x6ffffffa
PT_SUNWSTACK
0x6ffffffb
PT_SUNWDTRACE
0x6ffffffc
PT_SUNWCAP
0x6ffffffd
PT_HISUNW
0x6fffffff
PT_HIOS
0x6fffffff
PT_LOPROC
0x70000000
PT_HIPROC
0x7fffffff
PT_NULL

Unused. Member values are undefined. This type enables the program header table to contain ignored entries.

PT_LOAD

Specifies a loadable segment, described by p_filesz and p_memsz. The bytes from the file are mapped to the beginning of the memory segment. If the segment's memory size (p_memsz) is larger than the file size (p_filesz), the extra bytes are defined to hold the value 0. These bytes follow the initialized area of the segment. The file size can not be larger than the memory size. Loadable segment entries in the program header table appear in ascending order, and are sorted on the p_vaddr member.

PT_DYNAMIC

Specifies dynamic linking information. See Dynamic Section.

PT_INTERP

Specifies the location and size of a null-terminated path name to invoke as an interpreter. This type is mandatory for dynamic executable files. This type can occur in shared objects. This type cannot occur more than once in a file. This type, if present, must precede any loadable segment entries. See Program Interpreter for details.

PT_NOTE

Specifies the location and size of auxiliary information. See Note Section for details.

PT_SHLIB

Reserved but has unspecified semantics.

PT_PHDR

Specifies the location and size of the program header table, both in the file and in the memory image of the program. This segment type cannot occur more than once in a file. Moreover, this segment can occur only if the program header table is part of the memory image of the program. This type, if present, must precede any loadable segment entry. See Program Interpreter for details.

PT_TLS

Specifies a thread-local storage template. See Thread-Local Storage Section for details.

PT_LOOS - PT_HIOS

Values in this inclusive range are reserved for OS-specific semantics.

PT_SUNW_UNWIND

This segment contains the stack unwind tables.

PT_SUNW_EH_FRAME

This segment contains the stack unwind table. PT_SUNW_EH_FRAME is equivalent to PT_SUNW_EH_UNWIND.

PT_LOSUNW - PT_HISUNW

Values in this inclusive range are reserved for Sun-specific semantics.

PT_SUNWBSS

The same attributes as a PT_LOAD element and used to describe a .SUNW_bss section.

PT_SUNWSTACK

Describes a process stack. Only one PT_SUNWSTACK element can exist. Only access permissions, as defined in the p_flags field, are meaningful.

PT_SUNWDTRACE

Reserved for internal use by dtrace(1M).

PT_SUNWCAP

Specifies capability requirements. See Capabilities Section for details.

PT_LOPROC - PT_HIPROC

Values in this inclusive range are reserved for processor-specific semantics.


Note - Unless specifically required elsewhere, all program header segment types are optional. A file's program header table can contain only those elements that are relevant to its contents.


Base Address

Executable and shared object files have a base address, which is the lowest virtual address associated with the memory image of the program's object file. One use of the base address is to relocate the memory image of the program during dynamic linking.

An executable or shared object file's base address is calculated during execution from three values: the memory load address, the maximum page size, and the lowest virtual address of a program's loadable segment. The virtual addresses in the program headers might not represent the actual virtual addresses of the program's memory image. See Program Loading (Processor-Specific).

To compute the base address, you determine the memory address that are associated with the lowest p_vaddr value for a PT_LOAD segment. You then obtain the base address by truncating the memory address to the nearest multiple of the maximum page size. Depending on the kind of file being loaded into memory, the memory address might not match the p_vaddr values.

Segment Permissions

A program to be loaded by the system must have at least one loadable segment, although this restriction is not required by the file format. When the system creates loadable segment memory images, the system gives access permissions, as specified in the p_flags member. All bits that are included in the PF_MASKPROC mask are reserved for processor-specific semantics.

Table 13-2 ELF Segment Flags

Name
Value
Meaning
PF_X
0x1
Execute
PF_W
0x2
Write
PF_R
0x4
Read
PF_MASKPROC
0xf0000000
Unspecified

If a permission bit is 0, that bit's type of access is denied. Actual memory permissions depend on the memory management unit, which can vary between systems. Although all flag combinations are valid, the system can grant more access than requested. In no case, however, will a segment have write permission unless this permission is specified explicitly. The following table lists both the exact flag interpretation and the allowable flag interpretation.

Table 13-3 ELF Segment Permissions

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

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 consists of one or more sections, though this fact is transparent to the program header. Whether the file segment holds one section or many sections, is also immaterial to program loading. Nonetheless, various data must be present for program execution, dynamic linking, and so on. The following diagrams illustrate segment contents in general terms. The order and membership of sections within a segment can vary.

Text segments contain read-only instructions and data. Data segments contain writable-data and instructions. See Table 12-10 for a list of all special sections.

A PT_DYNAMIC program header element points at the .dynamic section. The .got and .plt sections also hold information related to position-independent code and dynamic linking.

The .plt can reside in a text or a data segment, depending on the processor. See Global Offset Table (Processor-Specific) and Procedure Linkage Table (Processor-Specific) for details.

Sections of type SHT_NOBITS occupy no space in the file, but contribute 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.