Linux Standard Base Specification for the IA32 Architecture 1.1.0

This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/) and provided that neither the name of the Free Standards Group, the name of the Linux Standard Base, nor the names of its contributors may be used to endorse or promote derived works without specific prior written permission.

Portions of the text were taken from other copyrighted documents in accordance with the respective license of those documents.


Table of Contents
I. Introduction
1. Introduction
Introduction
Purpose
Related Standards
Related Implementations
Relevant Libraries
How to Use this Standard
Definitions
Terminology
II. Low Level System Information
2. Machine Interface
Processor Architecture
Data Representation
3. Function Calling Sequence
CPU Registers
Floating Point Registers
Stack Frame
Arguments
Return Values
4. Operating System Interface
Virtual Address Space
Processor Execution Mode
Exception Interface
Signal Delivery
5. Process Initialization
Special Registers
Process Stack (on entry)
Auxilliary Vectors
Environment
6. Coding Examples
Code Model Overview/Architecture Constraints
Position-Independent Fucntion Prologue
Data Objects
Function Calls
Branching
7. C Stack Frame
Variable Argument List
Dynamic Allocation of Stack Space
8. Debug Information
III. Object Format
9. ELF Header
Machine Information
10. Sections
Special Sections
Linux Special Sections
Section Types
Section Attribute Flags
Special Section Types
11. Symbol Table
12. Relocation
Relocation Types
IV. Program Loading and Dynamic Linking
13. Program Header
Types
Flags
14. Program Loading
15. Dynamic Linking
Program Intepreter/Dynamic Linker
Dynamic Section
Global Offset Table
Shared Object Dependencies
Function Addresses
Procedure Linkage Table
Initialization and Termination Functions
V. Base Libraries
16. Libraries
Interfaces for libc
Data Definitions for libc
Interfaces Definitions for libc
Interfaces for libm
Data Definitions for libm
A. Alphabetical Listing of Interfaces
libc
List of Tables
1-1. Related Standards
1-2. Related Implementations
1-3. Relevant Libraries
2-1. Scalar Types
10-1.
10-2.
16-1. libc Definition
16-2. libc - Standard Library Function Interfaces
16-3. libc - Language Support Function Interfaces
16-4. libm Definition
A-1. libc Function Interfaces

I. Introduction

Table of Contents
1. Introduction

Chapter 1. Introduction

Introduction

This is version 1.1.0 of the Linux Standard Base Specification for the IA32 Architecture. An implementation of this version of the specification may not claim to be an implementation of the Linux Standard Base unless it has successfully completed the compliance process as defined by the Free Standards Group.


Purpose

The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.

The LSB defines a binary interface for application programs that are compiled and packaged for LSB-conforming implementations on many different hardware architectures. Since a binary specification must include information specific to the computer processor architecture for which it is intended, it is not possible for a single document to specify the interface for all possible LSB-conforming implementations. Therefore, the LSB is a family of specifications, rather than a single one.

The LSB is composed of two basic parts: A common part of the specification describes those parts of the interface that remain constant across all hardware implementations of the LSB, and an architecture-specific part of the specification describes the parts of the specification that are specific to a particular processor architecture. Together, the generic LSB and the architecture-specific supplement for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.

This document is the architecture-specific suppliment. It must be used in conjunction with the generic LSB. This document provides architecture-specific information that supplements the generic LSB as well as additional information that is not found in the generic LSB.

This document should be used in conjunction with the documents it references. This document enumerates the system components it includes, but descriptions of those components may be included entirely or partly in this document, partly in other documents, or entirely in other reference documents. For example, the section that describes system service routines includes a list of the system routines supported in this interface, formal declarations of the data structures they use that are visible to applications, and a pointer to the underlying referenced specification for information about the syntax and semantics of each call. Only those routines not described in standards referenced by this document, or extensions to those standards, are described in the detail. Information referenced in this way is as much a part of this document as is the information explicitly included here.


Related Standards

The specifications listed below are referenced in whole or in part by the Linux Standard Base. Such references may be normative or non-normative; a reference to specification shall only be considered normative if it is explicitly cited as such. The LSB may make normative references to a portion of these specifications (that is, to define a specific function or group of functions); in such cases, only the explicitly referenced portion of the specification is to be considered normative.

Table 1-1. Related Standards

System V Application Binary Interface - DRAFT - 22 June 2000http://www.caldera.com/developers/gabi/2000-07-17/contents.html 
Filesystem Hierarchy Standard 2.2http://www.pathname.com/fhs/ 
IEEE Standard for Binary Floating-Point Arithmetichttp://www.ieee.org/ANSI/IEEE Standards 745-1985 and 854-1987
System V Application Binary Interface, Edition 4.1http://www.caldera.com/developers/devspecs/gabi41.pdf 
IA32 Architecture Software Developer's Manual Volume 1: Basic Architecturehttp://developer.intel.com/design/pentiium4/manuals/24570.ht 
IA32 Architecture Software Developer's Manual Volume 2: Instruction Set Referencehttp://developer.intel.com/design/pentiium4/manuals/24571.ht 
IA32 Architecture Software Developer's Manual Volume 3: System Programming Guidehttp://developer.intel.com/design/pentiium4/manuals/24572.ht 
System V Application Binary Interface - Intel386 Architecture Processor Supplementhttp://www.caldera.com/developers/devspecs/abi386-4.pdf 
Itanium Architecture Software Developer's Manual Volume 1: Application Architecturehttp://developer.intel.com/design/itanium/downloads/24531702 
Itanium Architecture Software Developer's Manual Volume 2: System Architecturehttp://developer.intel.com/design/itanium/downloads/24531802 
Itanium Architecture Software Developer's Manual Volume 3: Instruction Set Referencehttp://developer.intel.com/design/itanium/downloads/24531902 
Itanium Architecture Software Developer's Manual Volume 4: Itanium Processor Programmer's Guidehttp://developer.intel.com/design/itanium/downloads/24532002 
Itanium(R) Software Conventions & Runtime Architecture Guidehttp://developer.intel.com/design/ia-64/downloads/245358.htm 
ISO/IEC 9899: 1990, Programming Languages --C 
ISO/IEC 9899: 1999, Programming Languages --C 
Linux Assigned Names And Numbers Authorityhttp://www.lanana.org/ 
Large File Supporthttp://www.UNIX-systems.org/version2/whatsnew/lfs20mar.html 
Linux Standard Basehttp://www.linuxbase.org/spec/ 
OpenGL® Application Binary Interface for Linuxhttp://oss.sgi.com/projects/ogl-sample/ABI/ 
IEEE Std POSIX 1003.2-1992 (ISO/IEC 9945-2:1993)http://www.ieee.org/ 
POSIX 1003.1chttp://www.ieee.org/ 
CAE Specification, May 1996, X/Open Curses, Issue 4, Version 2 (ISBN: 1-85912-171-3, C610), plus Corrigendum U018http://www.opengroup.org/ 
CAE Specification, January 1997, System Interface Definitions (XBD), Issue 5 (ISBN: 1-85912-186-1, C605)http://www.opengroup.org/ 
CAE Specification, January 1997, Commands and Utilities (XCU), Issue 5 (ISBN: 1-85912-191-8, C604)http://www.opengroup.org/ 
CAE Specification, February 1997, Networking Services (XNS), Issue 5 (ISBN: 1-85912-165-9, C523)http://www.opengroup.org/ 
CAE Specification, January 1997, System Interfaces and Headers (XSH), Issue 5 (ISBN: 1-85912-181-0, C606)http://www.opengroup.org/ 
The Single UNIX Specification Version 1 (UNIX 95) System Interfaces & Headershttp://www.opengroup.org/ 
System V Interface Definition, Issue 3ISBN 0201566524
System V Interface Definition,Fourth Edition 
Double Buffer Extension Libraryhttp://www.x.org/ 
X Display Power Management Signaling (DPMS) Extension, Library Specificationhttp://www.x.org/ 
X Record Extension Libraryhttp://www.x.org/ 
Security Extension Specification, Version 7.1http://www.x.org/ 
X Nonrectangular Window Shape Extension Library Version 1.0http://www.x.org/ 
MIT-SHM--The MIT Shared Memory Extensionhttp://www.x.org/ 
X Synchronization Extension Libraryhttp://www.x.org/ 
XTEST Extension Libraryhttp://www.x.org/ 
X11R6.4 X Inter-Client Exchange (ICE) Protocolhttp://www.x.org/ 
X11R6.4 X11 Input Extension Libraryhttp://www.x.org/ 
X11R6.4 Xlib - C libraryhttp://www.x.org/ 
X/Open Portability Guide, Issue 4http://www.opengroup.org/ 
X11R6.4 X Session Management Libraryhttp://www.x.org/ 
X11R.4 X Toolkit Intrinsicshttp://www.x.org/ 
zlib 1.1.3 Manualhttp://www.gzip.org/zlib/See

Related Implementations

The implementations listed here are referenced in whole or in part by the Linux Standard Base when no formal specification is available.

Table 1-2. Related Implementations

BSD 4.4 Lite version 2 
GNU/Linux defacto standardhttp://www.gnu.org/ 
RFC 1831 & 1832http://www.ietf.org/Still need API reference, instead of protocol reference
RPM Package Format V3.0http://www.rpmdp.org/rpmbook/ 

Relevant Libraries

The libraries listed here shall be available on a Linux Standard Base system. This list is an addition to the list in the general specification.

Table 1-3. Relevant Libraries

LibraryRuntime Name
libmlibm.so.6
libutillibutil.so.1
libclibc.so.6
libpthreadlibpthread.so.0
proginterp-ia32/lib/ld-lsb.so.1
librtlibrt.so.1

These libraries will be in an implementation-dependent directory which the dynamic linker will search by default.


How to Use this Standard

The complete LSB specification is composed of a generic LSB specification and this supplemental processor-specific specification. These two documents constitute a specification that should be used in conjunction with the publicly-available standards documents it references. The LSB enumerates the system components it includes, but descriptions of those components may be included entirely in the LSB, partly in the LSB and partly in other documents, or entirely in other reference documents.


Definitions

gLSB

This document.

LSB-Compliant Application

An application written to include only the system routines, commands, and other resources included in this document, and that has been compiled into an executable file that has the formats and characteristics specified for such files in this document, and whose behavior complies, installs, and is executed in the environment with the rules given in this document.

LSB-Conforming Implementation

An implementation that provides the binary system interface for applications described in this document.

Non-LSB-Compliant Application

An application which has been written to include system routines, commands, or other resources not included in this document, or which has been compiled into a different from those specified here, or which does not behave as specified in this document.

LSB Implementation Conformance

An implementation satisfying the following requirements:

  1. The implementation shall implement fully the architecture described in the hardware manual for the target processor architecture.

  2. The implementation shall be capable of executing compiled applications having the and using the system interfaces described in this document.

  3. The implementation shall provide libraries containing the interfaces specified by this document, and shall provide a dynamic linking mechanism that allows these interfaces to be attached to applications at runtime. All the interfaces shall behave as specified in the normative references and requirements of this document.

  4. The map of virtual memory provided by the implementation shall conform to the requirements of this document.

  5. The implementation's low-level behavior with respect to function call linkage, system traps, signals, and other such activities shall conform to the formats described in this document.

  6. The compilation system shall compile source code into executable files having the formats and characteristics specified in this document.

  7. The implementation shall provide all of the mandatory interfaces in their entirety.

  8. The implementation may provide one or more of the optional interfaces. Each optional interface that is provided shall be provided in its entirety. The product documentation shall state which optional interfaces are provided.

  9. The implementation shall provide all files and utilities specified as part of this document in the defined here and in other referenced documents. All commands and utilities shall behave as required by this document. The implementation shall also provide all mandatory components of an application's runtime environment that are included or referenced in this document.

  10. The implementation, when provided with standard data formats and values at a named interface, shall provide the behavior defined for those values and data formats at that interface. However, a conforming implementation may consist of components which are separately packaged and/or sold. For example, a vendor of a conforming implementation might sell the hardware, operating system, and windowing system as separately packaged items.

  11. The implementation may provide additional interfaces with different names. It may also provide additional behavior corresponding to data values outside the standard ranges, for standard named interfaces.

LSB Application Conformance

An application with the following characteristics:

  1. Its executable files are either shell scripts or object files in the defined for the Object File Format system interface.

  2. Its object files participate in dynamic linking as defined in the Program Loading and Linking System interface.

  3. It employs only the instructions, traps, and other low-level facilities defined in the Low-Level System interface as being for use by applications.

  4. If it requires any optional interface defined in this document in order to be installed or to execute successfully, the requirement for that optional interface is stated in the application's documentation.

  5. It does not use any interface or data that is not required to be provided by a conforming implementation, unless:

    • If such an interface or data is supplied by another application through direct invocation of that application during execution, that application is in turn an LSB-compliant application.

    • The use of that interface or data , as well as its source, is identified in the documentation of the application.

  6. It must not use any values for a named interface that are reserved for vendor extensions.

A strictly conforming application does not require or use any interface, facility, or implementation-defined extension that is not defined in this document in order to be installed or to execute successfully.

Rationale

An LSB-compliant application is expected to have no dependencies on any vendor extensions to this document. The most common such extensions are additional function entry points and additional libraries other than the ones defined in this document. If an application requires such extensions, it is not portable, since other LSB-conforming implementations may not provide those extensions.

An LSB-compliant application is required to use system services on the implementation on which it is running, rather than importing system routines from some other implementation. Thus, it must link dynamically to any routines in the implementation that perform system traps to kernel services.

It is to be expected that some applications may be companion applications to other applications. For example, a query application may be a companion to a database application; a preprocessor may be an adjunct to one or more compilers; a data reformatter may convert data from one document manager to another. In such cases, the application may or may not be LSB-compliant, regardless of whether the other application on which it is dependent is LSB-compliant. If such an application merely uses data produced by another application, the application's compliance is independent of the other application's compliance. If such an application actually invokes another application during execution (as, for example, a third-party math library), the invoking application is LSB-compliant only if it also constitutes a LSB-compliant application in combination with the invoked application.

Shell Script

A file that is read by an interpreter (e.g., awk). The first line of the shell script includes a reference to its interpreter binary.


Terminology

can

Describes a permissible optional feature or behavior available to the user or application. The feature or behavior is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.

implementation-defined

Describes a value or behavior that is not defined by this document but is selected by an implementor. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence of the value or behavior. An application that relies on such a value or behavior cannot be assured to be portable across conforming implementations. The implementor shall document such a value or behavior so that it can be used correctly by an application.

Same as implementation-dependent.

may

Describes a feature or behavior that is optional for an implementation that conforms to this document. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations.

To avoid ambiguity, the opposite of may is expressed as need not, instead of may not.

must

Describes a feature or behavior that is mandatory for an application or user. An implementation that conforms to this document shall support this feature or behavior.

shall

Describes a feature or behavior that is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.

should

For an implementation that conforms to this document, describes a feature or behavior that is recommended but not mandatory. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations.

For an application, describes a feature or behavior that is recommended programming practice for optimum portability.

undefined

Describes the nature of a value or behavior not defined by this document which results from use of an invalid program construct or invalid data input. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior cannot be assured to be portable across conforming implementations.

unspecified

Describes the nature of a value or behavior not specified by this document which results from use of a valid program construct or valid data input. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior cannot be assured to be portable across conforming implementations.

will

Same meaning as shall; shall is the preferred term.


Chapter 2. Machine Interface

Processor Architecture

The IA32 Architecture is specified by the following documents

  • Intel Architecture Software Developer's Manual, Volume 1: Basic Architecture

  • Intel Architecture Software Developer's Manual, Volume 2: Instruction Set Reference Manual

  • Intel Architecture Software Developer's Manual, Volume 3: System Programming Guide

Only the features of the Intel486 processor instruction set may be assumed to be present. An application is responsible for determining if any additional instruction set features are available before using those additional features. If a feature is not present, then the application may not use it.

Applications conforming to this specification must provide feedback to the user if a feature that is required for correct execution of the application is not present. Applications conforming to this specification should attempt to execute in a diminished capacity if a required instruction set feature is not present.

This specfication does not provide any performance guarantees of a conforming system. A system conforming to this specification may be implemented in either hardware or software.


Data Representation

LSB-conforming applications shall use the data representation as defined in Chapter 3 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.


Fundamental Types

In addition to the fundamental types specified in Chapter 3 of the System V Application Binary Interface - Intel386 Architecture, a 64 bit data type is defined here.

Table 2-1. Scalar Types

TypeCsizeofAlignment (bytes)IntelI386 Architecture
Integrallong long84signed double word
signed long long
unsigned long long84unsigned double word


Chapter 3. Function Calling Sequence

LSB-conforming applications shall use the function calling sequence as defined in Chapter 3 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.


Chapter 4. Operating System Interface

LSB-conforming applications shall use the Operating System Interfaces as defined in Chapter 3 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.


Chapter 5. Process Initialization

LSB-conforming applications shall use the Process Initialization as defined in Chapter 3 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.


Chapter 8. Debug Information

The LSB does not currently specify the format of Debug information.

III. Object Format

LSB-conforming implementations shall support an object file , called Executable and Linking Format (ELF) as defined by the System V Application Binary Interface, Edition 4.1, the System V Application Binary Interface - DRAFT - April 29, 1998, System V Application Binary Interface - Intel386 Architecture Processor Supplement and as supplemented by the Linux Standard Base Specification and this document.

Table of Contents
9. ELF Header
10. Sections
11. Symbol Table
12. Relocation

Chapter 9. ELF Header

Machine Information

LSB-conforming applications shall use the Machine Information as defined in Chapter 4 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.


Chapter 10. Sections


Special Sections

The following sections are defined in the System V Application Binary Interface - Intel386 Architecture Processor Supplement.

Table 10-1.

NameTypeAttributes
.gotSHT_PROGBITSSHF_ALLOC+SHF_WRITE
.pltSHT_PROGBITSSHF_ALLOC+SHF_EXECINSTR

.got

This section holds the global offset table.

.plt

This section holds the procedure linkage table.


Linux Special Sections

The following Linux IA-32 specific sections are defined here.

Table 10-2.

NameTypeAttributes
.sbssSHT_NOTESHF_WRITE

.sbss

Need a proper description


Chapter 11. Symbol Table

LSB-conforming applications shall use the Symbol Table as defined in Chapter 4 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.


Chapter 12. Relocation

LSB-conforming applications shall use Relocations as defined in Chapter 4 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.

IV. Program Loading and Dynamic Linking

LSB-conforming implementations shall support the object file information and system actions that create running programs as specified in the System V Application Binary Interface, Edition 4.1, the System V Application Binary Interface - DRAFT - April 29, 1998, System V Application Binary Interface - Intel386 Architecture Processor Supplement and as supplemented by the Linux Standard Base Specification and this document.


Chapter 15. Dynamic Linking


Program Intepreter/Dynamic Linker

The LSB specifies the Program Interpreter to be

  • /lib/ld-lsb.so.1


Dynamic Section

The following dynamic entries are defined in the System V Application Binary Interface - Intel386 Architecture Processor Supplement.

DT_PLTGOT

On the Intel386 architecture, this entrys d_ptr member gives the address of the first entry in the global offset table.

V. Base Libraries

Table of Contents
16. Libraries

Chapter 16. Libraries

An LSB-conforming implementation shall support some base libraries which provide interfaces for accessing the operating system, processor and other hardware in the system.

Interfaces that are unique to the IA32 platform are defined here. This section should be used in conjunction with the corresponding section in the Linux Standard Base Specification.


Interfaces for libc

Table 16-1. libc Definition

Library:libc
SONAME:libc.so.6

The behavior of the interfaces in this library is specified by the following standards.

Linux Standard Base[1]


Standard Library

Table 16-2. libc - Standard Library Function Interfaces

ioperm(GLIBC_2.0)[1]iopl(GLIBC_2.0)[1]   

Language Support

Table 16-3. libc - Language Support Function Interfaces

__divdi3(GLIBC_2.0)[1]    

Interfaces Definitions for libc

Table of Contents
__divdi3 -- mathematic operation
ioperm -- set port input/output permissions
iopl -- change I/O privilege level

__divdi3

Name

__divdi3 -- mathematic operation

Synopsis

DItype
__divdi3(DItype u, DItype v);

Description

__divdi3() divides two DItypes(unsigned ints).

__divdi3 is not in the source standard; it is only in the binary standard.

ioperm

Name

ioperm -- set port input/output permissions

Synopsis

#include <unistd.h> /* for libc5 */
#include <sys/io.h> /* for glibc */

int ioperm(unsigned long from, unsigned long num, int turn_on);

Description

ioperm sets the port access permission bits for the process for num bytes starting from port address from to the value turn_on. The use of ioperm requires root privileges.

Only the first 0x3ff I/O ports can be specified in this manner. For more ports, the iopl function must be used. Permissions are not inherited on fork, but on exec they are. This is useful for giving port access permissions to non-privileged tasks.

Return Value

On success, zero is returned. On error, -1 is returned, and errno is set appropriately.

Notes

Libc5 treats it as a system call and has a prototype in <unistd.h>. Glibc1 does not have a prototype. Glibc2 has a prototype both in <sys/io.h> and in <sys/perm.h>. Avoid the latter, it is available on i386 only.

iopl

Name

iopl -- change I/O privilege level

Synopsis

#include <unistd.h> /* for libc5 */
#include <sys/io.h> /* for glibc */

int iopl(int level);

Description

iopl changes the I/O privilege level of the current process, as specified in level.

This call is necessary to allow 8514-compatible X servers to run under Linux. Since these X servers require access to all 65536 I/O ports, the ioperm call is not sufficient.

In addition to granting unrestricted I/O port access, running at a higher I/O privilege level also allows the process to disable interrupts. This will probably crash the system, and is not recommended.

Permissions are inherited by fork and exec.

The I/O privilege level for a normal process is 0.

Return Value

On success, zero is returned. On error, -1 is returned, and errno is set appropriately.

Errors

EINVAL

level is greater than 3.

EPERM

The current user is not the super-user.

Notes from the Kernel Source

iopl has to be used when you want to access the I/O ports beyond the 0x3ff range: to get the full 65536 ports bitmapped you'd need 8kB of bitmaps/process, which is a bit excessive.

Notes

Libc5 treats it as a system call and has a prototype in <unistd.h>. Glibc1 does not have a prototype. Glibc2 has a prototype both in <sys/io.h> and in <sys/perm.h>. Avoid the latter, it is available on i386 only.


Interfaces for libm

Table 16-4. libm Definition

Library:libm
SONAME:libm.so.6


Appendix A. Alphabetical Listing of Interfaces


libc

The behaviour of the interfaces in this library is specified by the following Standards.

Linux Standard Base

Table A-1. libc Function Interfaces

__divdi3(GLIBC_2.0)[1]ioperm(GLIBC_2.0)[1]iopl(GLIBC_2.0)[1]

Notes

[1]

Linux Standard Base