The 32-bit PA-RISC Run- time Architecture Document HP-UX 10.20 Version 3.0 (c) Copyright 1985-1997 HEWLETT-PACKARD COMPANY. The information contained in this document is subject to change without notice. HEWLETT-PACKARD MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with furnishing, performance, or use of this material. Hewlett-Packard assumes no responsibility for the use or reliability of its software on equipment that is not furnished by Hewlett-Packard. This document contains proprietary information which is protected by copyright. All rights are reserved. No part of this document may be photocopied, reproduced, or translated to another language without the prior written consent of Hewlett- Packard Company. CSO/STG/STD/CLO Hewlett-Packard Company 11000 Wolfe Road Cupertino, California 95014 By The Run-time Architecture Team CHAPTER 1 Introduction This document describes the runtime architecture for PA-RISC systems running either the HP-UX or the MPE/iX operating system. Other operating systems running on PA-RISC may also use this runtime architecture or a variant of it. The runtime architecture defines all the conventions and formats necessary to compile, link, and execute a program on one of these operating systems. Its purpose is to ensure that object modules produced by many different compilers can be linked together into a single application, and to specify the interfaces between compilers and linker, and between linker and operating system. The runtime architecture applies only to hardware platforms based on PA-RISC Revi- sion 1.0 , 1.1, or 2.0. The runtime architecture does not specify the application programming interface (API), the set of services provided by the operating system to the program. Thus, observing the runtime architecture does not automatically lead to a program that will run on all PA-RISC platforms. It does, however, allow many of the development tools to be shared to a large extent among the various operating systems. When combined with a particular API, this runtime architecture leads to an application binary interface (ABI). In other words, an ABI can be regarded as the composition of an API, a hardware description, and a runtime architecture for that hardware. 1.1 Target Audiences This document is intended for a variety of readers. If you are a systems programmer, you will find information in this document describing the format of an executable object file, the memory model and startup environment The 32-bit PA-RISC RUN-TIME ARCHITECTURE DOCUMENT 3 Introduction assumed by a valid program, and the architected interface between a program and the services provided by your operating system. Chapters 5–7 will be of primary interest. If you develop compilers or other development tools, you will find information in this document about calling conventions and other coding conventions, the object file for- mat, interfaces to the linker, symbolic debug format, and other details important to pro- gram translation. Chapters 2–4 and 8–10 will be of primary interest; the other chapters may also contain relevant information. If you are an application programmer, this document can help you learn about the low- level details of how programs execute on PA-RISC. If you need to write assembly code, process object files, examine the stack, or perform dynamic linking, you will find the necessary information in this document. Chapters 2, 5, 9, and 11 will be of primary interest. 1.2 Overview of the PA-RISC Runtime Architecture Document Chapter 2 describes the coding conventions used by compilers and by assembly- language programmers. This includes details of the virtual memory model, usage of processor registers, external name conventions, addressing data, procedure calling and parameter passing, and the program startup environment. Chapter 3 describes the format of relocatable object files, and Chapter 4 describes the format of relocatable libraries. Chapter 5 describes the format of program files in general, while Chapters 6 and 7 cover details specific to the HP-UX and MPE/iX operating systems, respectively. These chap- ters also cover shared libraries and executable libraries. Chapter 8 describes the format of the symbolic debug information generated by the HP compilers and used by the xdb debugger. Chapter 9 describes the details of stack unwinding, and the interfaces to the stack unwind library provided by HP. Chapter 10 describes the library of millicode routines provided for the use of HP com- pilers. Chapter 11 describes the principles of dynamic linking—that is, dynamically loading relocatable objects into the address space of a running process. 4 HP PROPRIETARY CHAPTER 2 Common Coding Conventions 2.1 Memory Model The PA-RISC virtual memory is a set of linear spaces. Each space is four gigabytes (232 bytes) in size and is divided into four equal portions of one gigabyte (230 bytes each), known as quadrants. The four quadrants in a space are numbered 0,1,2, and 3, from low memory to high memory. An application can address 216 spaces. Each application has its own short address space composed of these four distinct quadrants (can possibly be four distinct spaces). 2.1.1 Text Segment The first quadrant (quadrant 0) of the short address space is mapped by space register 4 to the first quadrant of a space containing the shared text.The text is readable and exe- cutable, but not writable and must begin at a page boundary. An application must not change the contents of space register 4. This area of memory is used to store code (machine instructions), and literals only. The text address begins at 0x00000000 and ends at 0x3FFFFFFF. 2.1.2 Initialized and Unitialized Data Segments The second quadrant (quadrant 1) of the short address space is mapped by space register 5 to the second quadrant of a space containing the private data of applications. The data section is readable, writable, and executable and must begin at a page boundary. The private data includes the initialized data, the uninitialized data (BSS), the heap and the user stack. PA-RISC RUN-TIME ARCHITECTURE DOCUMENT 5 Common Coding Conventions Data segments start at 0x40000000 and end at 0x7FFFFFFF. 2.1.3 Shared Memory The third and fourth quadrant (quadrant 2 and 3) of the short address space is mapped by space register 6 and 7 to quadrants containing shared memory. Those portions of the shared memory that have been legally attached to the process via shared data memory system calls are readable and writable. The upper 256 megabytes of the fourth quadrant is not readable, writable, or executable by applications. The first page of the fourth quadrant is the Gateway page. Shared memory starts at 0x80000000 and ends at 0xFFFFFFFF. 2.1.4 Subspaces While a space is a fundamental concept of the architecture, a subspace is just a logical subdivision of a space. The linker groups subspaces into spaces as it builds an executa- bles program file. On HP-UX systems, all subspaces in the code space must be in quad- rant 0, and all subspaces in the data space must be in quadrant 1. 2.2 Register Usage 2.2.1 Data Pointer (GR 27) By software convention, general register GR 27 is used to point to the beginning address of global data in the data segment ($PRIVATE space). The start up code for each process sets up this address which is also known as the address of symbol $global$. Compilers and the linker then use this symbol to assign global data or to relocate data addresses. 2.2.2 Linkage Table Register (GR 19) The general purpose caller-saves register GR 19 has a special meaning in HP-UX shared library. In an HP-UX shared library, register GR 19 is used for the Data Linkage Table. Each shared library and incomplete executable contains a linkage table, which is allo- cated in the DATA space for the file. The linkage table is divided into two parts, the Data Linkage Table (DLT), and the Procedure Linkage Table (PLT). The PLT contains an entry for each unresolved procedure symbol referenced within the object and it is placed immediately following the DLT (if one exists). The DLT contains an entry for each data or procedure symbol that is accessed indirectly. Each DLT entry is a single word which contains a pointer to the actual data item refer- enced indirectly; this pointer value is assigned by the dynamic loader, after mapping the shared library. All references to data items go directly through the DLT and GR 19 is 6 HP PROPRIETARY Version 3.0 reserved to point to the middle of this table. The linker allocates GR 19-relative offsets for each DLT entry, and uses those offsets when applying fixups. 2.2.3 Stack Pointer (GR 30) Because no explicit procedure call stack exists in the PA-RISC processor architecture, the stack is defined and manipulated entirely by software convention. By convention, GR 30 is used for the stack pointer. The stack pointer always points to the first unused byte of data segment beyond the stack frame marker, and is 64-byte aligned. When a process is initiated by the operating system, a virtual address range is allocated for that process to be used for the call stack, and the stack pointer (GR 30) is initialized to point to the low end of this range. As procedures are called, the stack pointer is incre- mented to allow the called procedure frame to exist at the address below the stack pointer.