S/390 ELF Application Binary Interface Supplement | ||
---|---|---|
<<< Previous | Low-level system information | Next >>> |
Processes execute in a 31-bit virtual address space. Memory management translates virtual addresses to physical addresses, hiding physical addressing and letting a process run anywhere in the system's real memory. Processes typically begin with three logical segments, commonly called "text", "data" and "stack". An object file may contain more segments (for example, for debugger use), and a process can also create additional segments for itself with system services.
![]() | The term "virtual address" as used in this document refers to a 31-bit address generated by a program, as contrasted with the physical address to which it is mapped. |
Memory is organized into pages, which are the system's smallest units of memory allocation. The hardware page size for the ESA/390 architecture is 4096 bytes.
Processes have the full 31-bit address space available to them.
Figure 19 shows the virtual address configuration on the S/390 architecture. The segments with different properties are typically grouped in different areas of the address space. The loadable segments may begin at zero (0); the exact addresses depend on the executable file format (see the chapter called Object files and the chapter called Program loading and dynamic linking). The process' stack resides at the end of the virtual memory and grows downwards. Processes can control the amount of virtual memory allotted for stack space, as described below.
![]() | Although application programs may begin at virtual address 0, they conventionally begin above 0x1000 (4 Kbytes), leaving the initial 4 Kbytes with an invalid address mapping. Processes that reference this invalid memory (for example by de-referencing a null pointer) generate an translation exception as described in the Section called Exception interface. |
Although applications may control their memory assignments, the typical arrangement follows the diagram above. When applications let the system choose addresses for dynamic segments (including shared object segments), the system will prefer addresses in the upper half of the address space (above 1 Gbyte).
The section the Section called Process initialization describes the initial stack contents. Stack addresses can change from one system to the next – even from one process execution to the next on a single system. A program, therefore, should not depend on finding its stack at a particular virtual address.
A tunable configuration parameter controls the system maximum stack size. A process can also use setrlimit to set its own maximum stack size, up to the system limit. The stack segment is both readable and writable.
Operating system facilities, such as mmap, allow a process to establish address mappings in two ways. Firstly, the program can let the system choose an address. Secondly, the program can request the system to use an address the program supplies. The second alternative can cause application portability problems because the requested address might not always be available. Differences in virtual address space can be particularly troublesome between different architectures, but the same problems can arise within a single architecture.
Processes' address spaces typically have three segments that can change size from one execution to the next: the stack (through setrlimit); the data segment (through malloc); and the dynamic segment area (through mmap). Changes in one area may affect the virtual addresses available for another. Consequently an address that is available in one process execution might not be available in the next. Thus a program that used mmap to request a mapping at a specific address could appear to work in some environments and fail in others. For this reason programs that want to establish a mapping in their address space should let the system choose the address.
Despite these warnings about requesting specific addresses the facility can be used properly. For example, a multiprocess application might map several files into the address space of each process and build relative pointers among the files' data. This could be done by having each process ask for a certain amount of memory at an address chosen by the system. After each process receives its own private address from the system it would map the desired files into memory at specific addresses within the original area. This collection of mappings could be at different addresses in each process but their relative positions would be fixed. Without the ability to ask for specific addresses, the application could not build shared data structures because the relative positions for files in each process would be unpredictable.
Two execution modes exist in the ESA/390 architecture: problem (user) state and supervisor state. Processes run in problem state (the less privileged). The operating system kernel runs in supervisor state. A program executes an supervisor call (svc) instruction to change execution modes.
Note that the ABI does not define the implementation of individual system calls. Instead programs shall use the system libraries. Programs with embedded system call or trap instructions do not conform to the ABI.
<<< Previous | Home | Next >>> |
Function calling sequence | Up | Exception interface |