Linux Standard Base Specification for the IA32 Architecture 1.1.0

Linux Standard Base Specification for the IA32 Architecture 1.1.0
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.

Table of Contents
I. Introduction	000
1. Introduction	000
1.1. Introduction	000
1.2. Purpose	000
1.3. Related Standards	000
1.4. Related Implementations	000
1.5. Relevant Libraries	000
1.6. How to Use this Standard	000
1.7. Definitions	000
1.8. Terminology	000
II. Low Level System Information	000
2. Machine Interface	000
2.1. Processor Architecture	000
2.2. Data Representation	000
2.2.1. Byte Ordering	000
2.2.2. Fundamental Types	000
2.2.3. Aggregates and Unions	000
2.2.4. Bit Fields	000
3. Function Calling Sequence	000
3.1. CPU Registers	000
3.2. Floating Point Registers	000
3.3. Stack Frame	000
3.4. Arguments	000
3.4.1. Integral/Pointer	000
3.4.2. Floating Point	000
3.4.3. Struct and Union Point	000
3.4.4. Variable Arguments	000
3.5. Return Values	000
3.5.1. Void	000
3.5.2. Integral/Pointer	000
3.5.3. Floating Point	000
3.5.4. Struct and Union Point	000
4. Operating System Interface	000
4.1. Virtual Address Space	000
4.1.1. Page Size	000
4.1.2. Virtual Address Assignments	000
4.1.3. Managing the PRocess Stack	000
4.1.4. Coding Guidlines	000
4.2. Processor Execution Mode	000
4.3. Exception Interface	000
4.3.1. Hardware Exception Types	000
4.3.2. Software Trap Types	000
4.4. Signal Delivery	000
4.4.1. Signal Handler Interface	000
5. Process Initialization	000
5.1. Special Registers	000
5.2. Process Stack (on entry)	000
5.3. Auxilliary Vectors	000
5.4. Environment	000
6. Coding Examples	000
6.1. Code Model Overview/Architecture Constraints	000
6.2. Position-Independent Fucntion Prologue	000
6.3. Data Objects	000
6.3.1. Absolute Load & Store	000
6.3.2. Position Relative Load & Store	000
6.4. Function Calls	000
6.4.1. Absolute Direct Function Call	000
6.4.2. Absolute Indirect Function Call	000
6.4.3. Position-Independent Direct Function Call	000
6.4.4. Position-Independent Indirect Function Call	000
6.5. Branching	000
6.5.1. Branch Instruction	000
6.5.2. Absolute switch() code	000
6.5.3. Position-Independent switch() code	000
7. C Stack Frame	000
7.1. Variable Argument List	000
7.2. Dynamic Allocation of Stack Space	000
8. Debug Information	000
III. Object Format	000
9. ELF Header	000
9.1. Machine Information	000
9.1.1. File Class	000
9.1.2. Data Encoding	000
9.1.3. OS Identification	000
9.1.4. Processor Identification	000
9.1.5. Processor Specific Flags	000
10. Sections	000
10.1. Special Sections	000
10.2. Linux Special Sections	000
10.3. Section Types	000
10.4. Section Attribute Flags	000
10.5. Special Section Types	000
11. Symbol Table	000
12. Relocation	000
12.1. Relocation Types	000
IV. Program Loading and Dynamic Linking	000
13. Program Header	000
13.1. Types	000
13.2. Flags	000
14. Program Loading	000
15. Dynamic Linking	000
15.1. Program Intepreter/Dynamic Linker	000
15.2. Dynamic Section	000
15.3. Global Offset Table	000
15.4. Shared Object Dependencies	000
15.5. Function Addresses	000
15.6. Procedure Linkage Table	000
15.7. Initialization and Termination Functions	000
V. Base Libraries	000
16. Libraries	000
16.1. Interfaces for libc	000
16.1.1. Standard Library	000
16.1.2. Language Support	000
16.2. Data Definitions for libc	000
16.3. Interfaces Definitions for libc	000
__divdi3	000
ioperm	000
iopl	000
16.4. Interfaces for libm	000
16.5. Data Definitions for libm	000
A. Alphabetical Listing of Interfaces	000
A.1. libc	000

List of Tables
1-1. Related Standards	000
1-2. Related Implementations	000
1-3. Relevant Libraries	000
2-1. Scalar Types	000
10-1. 	000
10-2. 	000
16-1. libc Definition	000
16-2. libc - Standard Library Function Interfaces	000
16-3. libc - Language Support Function Interfaces	000
16-4. libm Definition	000
A-1. libc Function Interfaces	000

I. Introduction

Chapter 1. Introduction
1.1. 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.
1.2. 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.
1.3. 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 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	

1.4. 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 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/	

1.5. 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
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.
1.6. 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.
1.7. 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.
1.8. 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.

II. Low Level System Information

Chapter 2. Machine Interface
2.1. 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.
2.2. 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.
2.2.1. Byte Ordering
2.2.2. 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
Type	C	sizeof	Alignment (bytes)	IntelI386 Architecture	
Integral	long long	8	4	signed double word	
	signed long long	

	
	unsigned long long	8	4	unsigned double word	

2.2.3. Aggregates and Unions
2.2.4. Bit Fields

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.
3.1. CPU Registers
3.2. Floating Point Registers
3.3. Stack Frame
3.4. Arguments
3.4.1. Integral/Pointer
3.4.2. Floating Point
3.4.3. Struct and Union Point
3.4.4. Variable Arguments
3.5. Return Values
3.5.1. Void
3.5.2. Integral/Pointer
3.5.3. Floating Point
3.5.4. Struct and Union Point

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.
4.1. Virtual Address Space
4.1.1. Page Size
4.1.2. Virtual Address Assignments
4.1.3. Managing the PRocess Stack
4.1.4. Coding Guidlines
4.2. Processor Execution Mode
4.3. Exception Interface
4.3.1. Hardware Exception Types
4.3.2. Software Trap Types
4.4. Signal Delivery
4.4.1. Signal Handler Interface

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.
5.1. Special Registers
5.2. Process Stack (on entry)
5.3. Auxilliary Vectors
5.4. Environment

Chapter 6. Coding Examples
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.
6.1. Code Model Overview/Architecture Constraints
6.2. Position-Independent Fucntion Prologue
6.3. Data Objects
6.3.1. Absolute Load & Store
6.3.2. Position Relative Load & Store
6.4. Function Calls
6.4.1. Absolute Direct Function Call
6.4.2. Absolute Indirect Function Call
6.4.3. Position-Independent Direct Function Call
6.4.4. Position-Independent Indirect Function Call
6.5. Branching
6.5.1. Branch Instruction
6.5.2. Absolute switch() code
6.5.3. Position-Independent switch() code

Chapter 7. C Stack Frame
7.1. Variable Argument List
7.2. Dynamic Allocation of Stack Space

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.

Chapter 9. ELF Header
9.1. 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.
9.1.1. File Class
9.1.2. Data Encoding
9.1.3. OS Identification
9.1.4. Processor Identification
9.1.5. Processor Specific Flags

Chapter 10. Sections
10.1. Special Sections
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	

.got
 	This section holds the global offset table.
.plt
 	This section holds the procedure linkage table.
10.2. Linux Special Sections
The following Linux IA-32 specific sections are defined here. 
Table 10-2. 
Name	Type	Attributes	
.sbss	SHT_NOTE	SHF_WRITE	

.sbss
 	Need a proper description
10.3. Section Types
10.4. Section Attribute Flags
10.5. Special Section Types

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.
12.1. Relocation Types

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 13. Program Header
13.1. Types
13.2. Flags

Chapter 14. Program Loading

Chapter 15. Dynamic Linking
15.1. Program Intepreter/Dynamic Linker
The LSB specifies the Program Interpreter to be 
•	/lib/ld-lsb.so.1
15.2. 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.
15.3. Global Offset Table
15.4. Shared Object Dependencies
15.5. Function Addresses
15.6. Procedure Linkage Table
15.7. Initialization and Termination Functions

V. Base 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.
16.1. 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 Base1	

16.1.1. Standard Library
Table 16-2. libc - Standard Library Function Interfaces
ioperm(GLIBC_2.0)1	iopl(GLIBC_2.0)1	

	

16.1.2. Language Support
Table 16-3. libc - Language Support Function Interfaces
__divdi3(GLIBC_2.0)1	

	

16.2. Data Definitions for libc
16.3. Interfaces Definitions for libc
__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.
16.4. Interfaces for libm
Table 16-4. libm Definition
Library:	libm	
SONAME:	libm.so.6	

16.5. Data Definitions for libm
Notes
1. 	Linux Standard Base

Appendix A. Alphabetical Listing of Interfaces
A.1. 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