Program loading (processor-specific)

Developer's Topics
Chapter 8, ELF object files

As the system creates or augments a process image, it 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 it references the logical page during execution, and processes commonly leave many pages unreferenced. Therefore delaying physical reads frequently obviates them, improving system performance. To obtain this efficiency in practice, executable and shared object files must have segment images whose file offsets and virtual addresses are congruent, modulo the page size. By aligning segments to the maximum page size, the files will be suitable for paging regardless of physical page size.

The following examples show 8 K alignment; virtual addresses and file offsets for segments are congruent modulo 8 K (0x2000). Actual minimum page sizes are machine specific.

 ------------------------------------------------------
| File offset   File                   Virtual address|
|-----------------------------------------------------|
| 0             ELF header                            |
|              ----------------------                 |
|               Program header table                  |
|              ----------------------                 |
|               Other information                     |
|              ----------------------                 |
| 0x100         Text segment           0x80000100     |
|               . . .                                 |
|               0x2be00 bytes          0x8002beff     |
|              ----------------------                 |
| 0x2bf00       Data segment           0x8002df00     |
|               . . .                                 |
|               0x4e00 bytes           0x80032cff     |
|              ----------------------                 |
| 0x30d00       Other information                     |
|               . . .                                 |
|-----------------------------------------------------|

Figure 8-13 Executable file

Table 8-16 Program header segments

 ---------------------------------------------------------------------
 Member          Text            Data
 ---------------------------------------------------------------------
 p_type          PT_LOAD         PT_LOAD
 p_offset        0x100           0x2bf00
 p_vaddr         0x80000100      0x8002df00
 p_paddr         unspecified     unspecified
 p_filesz        0x2be00         0x4e00
 p_memsz         0x2be00         0x5e24
 p_flags         PF_R+PF_X       PF_R+PF_W+PF_X
 p_align         0x2000          0x2000

Although 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).

The first text page contains the ELF header, the program header table, and other information.
The last text page holds a copy of the beginning of data.
The first data page has a copy of the end of text.
The last data page may contain file information not relevant to the running process.

Logically, the system enforces the memory permissions as if each segment were complete and separate; segments' addresses are adjusted to ensure each logical page in the address space has a single set of permissions. In the previous example, the region of the file holding the end of text and the beginning of data will be mapped twice: at one virtual address for text and at a different virtual address for data.

The end of the data segment requires special handling for uninitialized data, which the system defines to begin with zero values. Thus 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 them is unspecified. The memory image for this program follows, assuming 2KB (0x800) pages. For simplicity, this example illustrates only one page size.

 ----------------------------------------------
 Virtual address   Contents             Segment
 ----------------------------------------------
 0x80000000        Header padding       Text
                   0x100 bytes
                  --------------------
 0x80000100        Text segment

                   . . .

                   0x2be00 bytes
                  --------------------
 0x8002bf00        Data padding
                   0x100 bytes
                  --------------------

                | -------------------|
 0x8002d800     |     Text padding   |   Data
                |     0x700 bytes    |
                | -------------------|
 0x8002df00     |     Data segment   |
                |                    |
                |        . . .       |
                |                    |
                |     0x4e00 bytes   |
                | -------------------|
 0x80032d00     |  Uninitialized data|
                |  0x1024 zero bytes |
                | -------------------|
 0x80033d24     |     Page padding   |
                |   0x2dc zero bytes |
                | -------------------|

Figure 8-14 Process image segments

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

On the other hand, shared object segments typically contain position-independent code.

NOTE: See ``Link editing'' in the Programming Tools Guide for more information.

This lets a segment's virtual address change from one process to another, without invalidating execution behavior. Though the system chooses virtual addresses for individual processes, it maintains the segments' relative positions. 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. Table 8-17, ``Example shared object segment addresses'' shows possible shared object virtual address assignments for several processes, illustrating constant relative positioning. The table also illustrates the base address computations. The maximum page size used in Table 8-17, ``Example shared object segment addresses'' is 8KB.

Table 8-17 Example shared object segment addresses

 --------------------------------------------------
 Source      Text         Data         Base address
 --------------------------------------------------
 File        0x200        0x2a400      0x0
 Process 1   0xc0080200   0xc00aa400   0xc0080000
 Process 2   0xc0082200   0xc00ac400   0xc0082000
 Process 3   0xd00c0200   0xd00ea400   0xd00c0000
 Process 4   0xd00c6200   0xd00f0400   0xd00c6000