Copyright © 2001 by Free Standards Group
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.
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.
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.
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 2000 | http://www.caldera.com/developers/gabi/2000-07-17/contents.html | |
| Filesystem Hierarchy Standard 2.2 | http://www.pathname.com/fhs/ | |
| IEEE Standard for Binary Floating-Point Arithmetic | http://www.ieee.org/ | ANSI/IEEE Standards 745-1985 and 854-1987 |
| System V Application Binary Interface, Edition 4.1 | http://www.caldera.com/developers/devspecs/gabi41.pdf | |
| IA32 Architecture Software Developer's Manual Volume 1: Basic Architecture | http://developer.intel.com/design/pentiium4/manuals/24570.ht | |
| IA32 Architecture Software Developer's Manual Volume 2: Instruction Set Reference | http://developer.intel.com/design/pentiium4/manuals/24571.ht | |
| IA32 Architecture Software Developer's Manual Volume 3: System Programming Guide | http://developer.intel.com/design/pentiium4/manuals/24572.ht | |
| System V Application Binary Interface - Intel386 Architecture Processor Supplement | http://www.caldera.com/developers/devspecs/abi386-4.pdf | |
| Itanium Architecture Software Developer's Manual Volume 1: Application Architecture | http://developer.intel.com/design/itanium/downloads/24531702 | |
| Itanium Architecture Software Developer's Manual Volume 2: System Architecture | http://developer.intel.com/design/itanium/downloads/24531802 | |
| Itanium Architecture Software Developer's Manual Volume 3: Instruction Set Reference | http://developer.intel.com/design/itanium/downloads/24531902 | |
| Itanium Architecture Software Developer's Manual Volume 4: Itanium Processor Programmer's Guide | http://developer.intel.com/design/itanium/downloads/24532002 | |
| Itanium(R) Software Conventions & Runtime Architecture Guide | http://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 Authority | http://www.lanana.org/ | |
| Large File Support | http://www.UNIX-systems.org/version2/whatsnew/lfs20mar.html | |
| Linux Standard Base | http://www.linuxbase.org/spec/ | |
| OpenGL® Application Binary Interface for Linux | http://oss.sgi.com/projects/ogl-sample/ABI/ | |
| IEEE Std POSIX 1003.2-1992 (ISO/IEC 9945-2:1993) | http://www.ieee.org/ | |
| POSIX 1003.1c | http://www.ieee.org/ | |
| CAE Specification, May 1996, X/Open Curses, Issue 4, Version 2 (ISBN: 1-85912-171-3, C610), plus Corrigendum U018 | http://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 & Headers | http://www.opengroup.org/ | |
| System V Interface Definition, Issue 3 | ISBN 0201566524 | |
| System V Interface Definition,Fourth Edition | ||
| Double Buffer Extension Library | http://www.x.org/ | |
| X Display Power Management Signaling (DPMS) Extension, Library Specification | http://www.x.org/ | |
| X Record Extension Library | http://www.x.org/ | |
| Security Extension Specification, Version 7.1 | http://www.x.org/ | |
| X Nonrectangular Window Shape Extension Library Version 1.0 | http://www.x.org/ | |
| MIT-SHM--The MIT Shared Memory Extension | http://www.x.org/ | |
| X Synchronization Extension Library | http://www.x.org/ | |
| XTEST Extension Library | http://www.x.org/ | |
| X11R6.4 X Inter-Client Exchange (ICE) Protocol | http://www.x.org/ | |
| X11R6.4 X11 Input Extension Library | http://www.x.org/ | |
| X11R6.4 Xlib - C library | http://www.x.org/ | |
| X/Open Portability Guide, Issue 4 | http://www.opengroup.org/ | |
| X11R6.4 X Session Management Library | http://www.x.org/ | |
| X11R.4 X Toolkit Intrinsics | http://www.x.org/ | |
| zlib 1.1.3 Manual | http://www.gzip.org/zlib/ | See |
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 standard | http://www.gnu.org/ | |
| RFC 1831 & 1832 | http://www.ietf.org/ | Still need API reference, instead of protocol reference |
| RPM Package Format V3.0 | http://www.rpmdp.org/rpmbook/ |
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
| Library | Runtime Name |
|---|---|
| libm | libm.so.6 |
| libutil | libutil.so.1 |
| libc | libc.so.6 |
| libpthread | libpthread.so.0 |
| proginterp-ia32 | /lib/ld-lsb.so.1 |
| librt | librt.so.1 |
These libraries will be in an implementation-dependent directory which the dynamic linker will search by default.
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.
This document.
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.
An implementation that provides the binary system interface for applications described in this document.
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.
An implementation satisfying the following requirements:
The implementation shall implement fully the architecture described in the hardware manual for the target processor architecture.
The implementation shall be capable of executing compiled applications having the and using the system interfaces described in this document.
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.
The map of virtual memory provided by the implementation shall conform to the requirements of this document.
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.
The compilation system shall compile source code into executable files having the formats and characteristics specified in this document.
The implementation shall provide all of the mandatory interfaces in their entirety.
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.
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.
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.
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.
An application with the following characteristics:
Its executable files are either shell scripts or object files in the defined for the Object File Format system interface.
Its object files participate in dynamic linking as defined in the Program Loading and Linking System interface.
It employs only the instructions, traps, and other low-level facilities defined in the Low-Level System interface as being for use by applications.
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.
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.
It must not use any values for a named interface that are reserved for vendor extensions.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Same meaning as shall; shall is the preferred term.
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.
LSB-conforming applications shall use the data representation as defined in Chapter 3 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.
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.
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.
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.
LSB-conforming applications shall use the Process Initialization as defined in Chapter 3 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.
LSB-conforming applications may implement fundamental operations using the Coding Examples as defined in Chapter 3 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.
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.
LSB-conforming applications shall use the Machine Information as defined in Chapter 4 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.
The following sections are defined in the System V Application Binary Interface - Intel386 Architecture Processor Supplement.
Table 10-1.
| Name | Type | Attributes |
|---|---|---|
| .got | SHT_PROGBITS | SHF_ALLOC+SHF_WRITE |
| .plt | SHT_PROGBITS | SHF_ALLOC+SHF_EXECINSTR |
This section holds the global offset table.
This section holds the procedure linkage table.
The following Linux IA-32 specific sections are defined here.
Need a proper description
LSB-conforming applications shall use the Symbol Table as defined in Chapter 4 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.
LSB-conforming applications shall use Relocations as defined in Chapter 4 of the System V Application Binary Interface - Intel386 Architecture Processor Supplement.
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.
The following dynamic entries are defined in the System V Application Binary Interface - Intel386 Architecture Processor Supplement.
On the Intel386 architecture, this entrys d_ptr member gives the address of the first entry in the global offset table.
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.
The behavior of the interfaces in this library is specified by the following standards.
| Linux Standard Base[1] |
__divdi3() divides two DItypes(unsigned ints).
__divdi3 is not in the source standard; it is only in the binary standard.
#include <unistd.h> /* for libc5 */ #include <sys/io.h> /* for glibc */ int ioperm(unsigned long from, unsigned long num, int turn_on); |
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.
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.
#include <unistd.h> /* for libc5 */ #include <sys/io.h> /* for glibc */ int iopl(int level); |
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.
| [1] | Linux Standard Base |