|
|
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 | |
| [. . .] |
Executable file
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 |
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 |
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.
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. ``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 ``Example shared object segment addresses'' is 8KB.
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 |