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 Loading (Processor-Specific)

As the system creates or augments a process image, the system logically copies a file's segment to a virtual memory segment. When, and if, the system physically reads the file depends on the program's execution behavior, system load, and so forth.

A process does not require a physical page unless the process references the logical page during execution. Processes commonly leave many pages unreferenced. Therefore, delaying physical reads can improve system performance. To obtain this efficiency in practice, executable files and shared object files must have segment images whose file offsets and virtual addresses are congruent, modulo the page size.

Virtual addresses and file offsets for 32–bit segments are congruent modulo 64K (0x10000). Virtual addresses and file offsets for 64–bit segments are congruent modulo 1 megabyte (0x100000). By aligning segments to the maximum page size, the files are suitable for paging regardless of physical page size.

By default, 64–bit SPARC programs are linked with a starting address of 0x100000000. The whole program is located above 4 gigabytes, including its text, data, heap, stack, and shared object dependencies. This helps ensure that 64–bit programs are correct because the program will fault in the least significant 4 gigabytes of its address space if the program truncates any of its pointers. While 64–bit programs are linked above 4 gigabytes, you can still link programs below 4 gigabytes by using a mapfile and the -M option to the link-editor. See /usr/lib/ld/sparcv9/map.below4G.

The following figure presents the SPARC version of the executable file.

Figure 13-1 SPARC: Executable File (64K alignment)

image:SPARC executable file layout example.

The following table defines the loadable segment elements for the previous figure.

Table 13-4 SPARC: ELF Program Header Segments (64K alignment)

Member
Text
Data
p_type
PT_LOAD
PT_LOAD
p_offset
0x0
0x4000
p_vaddr
0x10000
0x24000
p_paddr
Unspecified
Unspecified
p_filesize
0x3a82
0x4f5
p_memsz
0x3a82
0x10a4
p_flags
PF_R + PF_X
PF_R + PF_W + PF_X
p_align
0x10000
0x10000

The following figure presents the x86 version of the executable file.

Figure 13-2 32-bit x86: Executable File (64K alignment)

image:x86 executable file layout example.

The following table defines the loadable segment elements for the previous figure.

Table 13-5 32-bit x86: ELF Program Header Segments (64K alignment)

Member
Text
Data
p_type
PT_LOAD
PT_LOAD
p_offset
0x0
0x4000
p_vaddr
0x8050000
0x8064000
p_paddr
Unspecified
Unspecified
p_filesize
0x32fd
0x3a0
p_memsz
0x32fd
0xdc4
p_flags
PF_R + PF_X
PF_R + PF_W + PF_X
p_align
0x10000
0x10000

The example's file offsets and virtual addresses are congruent modulo the maximum page size for both text and data. Up to four file pages hold impure text or data depending on page size and file system block size.


Note - The previous examples reflect typical Oracle Solaris OS binaries that have their text segments rounded.


The end of the data segment requires special handling for uninitialized data, which the system defines to begin with zero values. If a file's last data page includes information not in the logical memory page, the extraneous data must be set to zero, not the unknown contents of the executable file.

Impurities in the other three pages are not logically part of the process image. Whether the system expunges these impurities is unspecified. The memory image for this program is shown in the following figures, assuming 4 Kbyte (0x1000) pages. For simplicity, these figures illustrate only one page size.

Figure 13-3 32-bit SPARC: Process Image Segments

image:SPARC process image segments example.

Figure 13-4 x86: Process Image Segments

image:x86 process image segments example.

One aspect of segment loading differs between executable files and shared objects. Executable file segments typically contain absolute code. For the process to execute correctly, the segments must reside at the virtual addresses used to create the executable file. The system uses the p_vaddr values unchanged as virtual addresses.

On the other hand, shared object segments typically contain position-independent code. This code enables a segment's virtual address change between different processes, without invalidating execution behavior.

Though the system chooses virtual addresses for individual processes, it maintains the relative positions of the segments. Because position-independent code uses relative addressing between segments, the difference between virtual addresses in memory must match the difference between virtual addresses in the file.

The following tables show possible shared object virtual address assignments for several processes, illustrating constant relative positioning. The tables also include the base address computations.

Table 13-6 32-bit SPARC: ELF Example Shared Object Segment Addresses

Source
Text
Data
Base Address
File
0x0
0x4000
0x0
Process 1
0xc0000000
0xc0024000
0xc0000000
Process 2
0xc0010000
0xc0034000
0xc0010000
Process 3
0xd0020000
0xd0024000
0xd0020000
Process 4
0xd0030000
0xd0034000
0xd0030000

Table 13-7 32-bit x86: ELF Example Shared Object Segment Addresses

Source
Text
Data
Base Address
File
0x0
0x4000
0x0
Process 1
0x8000000
0x8004000
0x80000000
Process 2
0x80081000
0x80085000
0x80081000
Process 3
0x900c0000
0x900c4000
0x900c0000
Process 4
0x900c6000
0x900ca000
0x900c6000

Program Interpreter

A dynamic executable or shared object that initiates dynamic linking can have one PT_INTERP program header element. During exec(2), the system retrieves a path name from the PT_INTERP segment and creates the initial process image from the interpreter file's segments. The interpreter is responsible for receiving control from the system and providing an environment for the application program.

In the Oracle Solaris OS, the interpreter is known as the runtime linker, ld.so.1(1).