Copyright © 2007 Linux Foundation
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".
Portions of the text may be copyrighted by the following parties:
The Regents of the University of California
Free Software Foundation
Ian F. Darwin
Paul Vixie
BSDI (now Wind River)
Andrew G Morgan
Jean-loup Gailly and Mark Adler
Massachusetts Institute of Technology
Apple Inc.
Easy Software Products
artofcode LLC
Till Kamppeter
Manfred Wassman
Python Software Foundation
These excerpts are being used in accordance with their respective licenses.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
UNIX is a registered trademark of The Open Group.
LSB is a trademark of the Linux Foundation in the United States and other countries.
AMD is a trademark of Advanced Micro Devices, Inc.
Intel and Itanium are registered trademarks and Intel386 is a trademark of Intel Corporation.
PowerPC is a registered trademark and PowerPC Architecture is a trademark of the IBM Corporation.
S/390 is a registered trademark of the IBM Corporation.
OpenGL is a registered trademark of Silicon Graphics, Inc.
This is version 3.2 of the Linux Standard Base Core Specification for AMD64. This specification is part of a family of specifications under the general title "Linux Standard Base". Developers of applications or implementations interested in using the LSB trademark should see the Linux Foundation Certification Policy for details.
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 shall 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.
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 specification carries a version number of either the form x.y or x.y.z. This version number carries the following meaning:
The first number (x) is the major version number. All versions with the same major version number should share binary compatibility. Any addition or deletion of a new library results in a new version number. Interfaces marked as deprecated may be removed from the specification at a major version change.
The second number (y) is the minor version number. Individual interfaces may be added if all certified implementations already had that (previously undocumented) interface. Interfaces may be marked as deprecated at a minor version change. Other minor changes may be permitted at the discretion of the LSB workgroup.
The third number (z), if present, is the editorial level. Only editorial changes should be included in such versions.
Since this specification is a descriptive Application Binary Interface, and not a source level API specification, it is not possible to make a guarantee of 100% backward compatibility between major releases. However, it is the intent that those parts of the binary interface that are visible in the source level API will remain backward compatible from version to version, except where a feature marked as "Deprecated" in one release may be removed from a future release.
Implementors are strongly encouraged to make use of symbol versioning to permit simultaneous support of applications conforming to different releases of this specification.
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.
These specifications are composed of two basic parts: A common specification ("LSB-generic" or "generic LSB"), ISO/IEC 23360 Part 1, describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part ("LSB-arch" or "archLSB") describing the parts of the interface that vary by processor architecture. Together, the LSB-generic and the relevant architecture-specific part of ISO/IEC 23360 for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture.
ISO/IEC 23360 Part 1, the LSB-generic document, should be used in conjunction with an architecture-specific part. Whenever a section of the LSB-generic specification is supplemented by architecture-specific information, the LSB-generic document includes a reference to the architecture part. Architecture-specific parts of ISO/IEC 23360 may also contain additional information that is not referenced in the LSB-generic document.
The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed.
The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.
This is the AMD64 architecture specific Core part of the Linux Standard Base (LSB). This part supplements the generic LSB Core module with those interfaces that differ between architectures.
Interfaces described in this part of ISO/IEC 23360 are mandatory except where explicitly listed otherwise. Core interfaces may be supplemented by other modules; all modules are built upon the core.
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
Note: Where copies of a document are available on the World Wide Web, a Uniform Resource Locator (URL) is given for informative purposes only. This may point to a more recent copy of the referenced specification, or may be out of date. Reference copies of specifications at the revision level indicated may be found at the Linux Foundation's Reference Specifications site.
Table 2-1. Normative References
| Name | Title | URL |
|---|---|---|
| ISO/IEC 23360 Part 1 | ISO/IEC 23360:2005 Linux Standard Base - Part 1 Generic Specification | http://www.linuxbase.org/spec/ |
| AMD64 Architecture Programmer's Manual, Volume 1 | AMD64 Architecture Programmer's Manual, Volume 1: Application Programming 24592 3.08 | http://www.amd.com/us-en/Processors/DevelopWithAMD/ |
| AMD64 Architecture Programmer's Manual, Volume 2 | AMD64 Architecture Programmer's Manual, Volume 2: System Programming 24593 3.08 | http://www.amd.com/us-en/Processors/DevelopWithAMD/ |
| AMD64 Architecture Programmer's Manual, Volume 3 | AMD64 Architecture Programmer's Manual, Volume 3: General Purpose and System Instructions 24594 3.03 | http://www.amd.com/us-en/Processors/DevelopWithAMD/ |
| AMD64 Architecture Programmer's Manual, Volume 4 | AMD64 Architecture Programmer's Manual, Volume 4: 128-bit Media Instructions 26568 3.04 | http://www.amd.com/us-en/Processors/DevelopWithAMD/ |
| AMD64 Architecture Programmer's Manual, Volume 5 | AMD64 Architecture Programmer's Manual, Volume 5: 64-bit Media and x87 Floating-Point Instructions 26569 3.03 | http://www.amd.com/us-en/Processors/DevelopWithAMD/ |
| Filesystem Hierarchy Standard | Filesystem Hierarchy Standard (FHS) 2.3 | http://www.pathname.com/fhs/ |
| ISO C (1999) | ISO/IEC 9899: 1999, Programming Languages --C | |
| ISO POSIX (2003) | ISO/IEC 9945-1:2003 Information technology -- Portable Operating System Interface (POSIX) -- Part 1: Base Definitions ISO/IEC 9945-2:2003 Information technology -- Portable Operating System Interface (POSIX) -- Part 2: System Interfaces ISO/IEC 9945-3:2003 Information technology -- Portable Operating System Interface (POSIX) -- Part 3: Shell and Utilities ISO/IEC 9945-4:2003 Information technology -- Portable Operating System Interface (POSIX) -- Part 4: Rationale Including Technical Cor. 1: 2004 | http://www.unix.org/version3/ |
| Large File Support | Large File Support | http://www.UNIX-systems.org/version2/whatsnew/lfs20mar.html |
| SUSv2 | CAE Specification, January 1997, System Interfaces and Headers (XSH),Issue 5 (ISBN: 1-85912-181-0, C606) | http://www.opengroup.org/publications/catalog/un.htm |
| SVID Issue 3 | American Telephone and Telegraph Company, System V Interface Definition, Issue 3; Morristown, NJ, UNIX Press, 1989. (ISBN 0201566524) | |
| SVID Issue 4 | System V Interface Definition, Fourth Edition | |
| System V ABI | System V Application Binary Interface, Edition 4.1 | http://www.caldera.com/developers/devspecs/gabi41.pdf |
| System V ABI Update | System V Application Binary Interface - DRAFT - 17 December 2003 | http://www.caldera.com/developers/gabi/2003-12-17/contents.html |
| System V Application Binary Interface AMD64 Architecture Processor Supplement | System V Application Binary Interface AMD64 Architecture Processor Supplement, Draft Version 0.95 | http://refspecs.linux-foundation.org/spec/elf/x86_64-abi-0.95.pdf |
| X/Open Curses | CAE Specification, May 1996, X/Open Curses, Issue 4, Version 2 (ISBN: 1-85912-171-3, C610), plus Corrigendum U018 | http://www.opengroup.org/publications/catalog/un.htm |
In addition, the specifications listed below provide essential background information to implementors of this specification. These references are included for information only.
Table 2-2. Other References
| Name | Title | URL |
|---|---|---|
| DWARF Debugging Information Format, Revision 2.0.0 | DWARF Debugging Information Format, Revision 2.0.0 (July 27, 1993) | http://refspecs.linux-foundation.org/dwarf/dwarf-2.0.0.pdf |
| DWARF Debugging Information Format, Revision 3.0.0 (Draft) | DWARF Debugging Information Format, Revision 3.0.0 (Draft) | http://refspecs.linux-foundation.org/dwarf |
| IEC 60559/IEEE 754 Floating Point | IEC 60559:1989 Binary floating-point arithmetic for microprocessor systems | http://www.ieee.org/ |
| ISO/IEC TR14652 | ISO/IEC Technical Report 14652:2002 Specification method for cultural conventions | |
| ITU-T V.42 | International Telecommunication Union Recommendation V.42 (2002): Error-correcting procedures for DCEs using asynchronous-to-synchronous conversionITUV | http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-V.42 |
| Li18nux Globalization Specification | LI18NUX 2000 Globalization Specification, Version 1.0 with Amendment 4 | http://www.openi18n.org/docs/html/LI18NUX-2000-amd4.htm |
| Linux Allocated Device Registry | LINUX ALLOCATED DEVICES | http://www.lanana.org/docs/device-list/devices.txt |
| PAM | Open Software Foundation, Request For Comments: 86.0 , October 1995, V. Samar & R.Schemers (SunSoft) | http://www.opengroup.org/tech/rfc/mirror-rfc/rfc86.0.txt |
| RFC 1321: The MD5 Message-Digest Algorithm | IETF RFC 1321: The MD5 Message-Digest Algorithm | http://www.ietf.org/rfc/rfc1321.txt |
| RFC 1831/1832 RPC & XDR | IETF RFC 1831 & 1832 | http://www.ietf.org/ |
| RFC 1833: Binding Protocols for ONC RPC Version 2 | IETF RFC 1833: Binding Protocols for ONC RPC Version 2 | http://www.ietf.org/rfc/rfc1833.txt |
| RFC 1950: ZLIB Compressed Data Format Specication | IETF RFC 1950: ZLIB Compressed Data Format Specification | http://www.ietf.org/rfc/rfc1950.txt |
| RFC 1951: DEFLATE Compressed Data Format Specification | IETF RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 | http://www.ietf.org/rfc/rfc1951.txt |
| RFC 1952: GZIP File Format Specification | IETF RFC 1952: GZIP file format specification version 4.3 | http://www.ietf.org/rfc/rfc1952.txt |
| RFC 2440: OpenPGP Message Format | IETF RFC 2440: OpenPGP Message Format | http://www.ietf.org/rfc/rfc2440.txt |
| RFC 2821:Simple Mail Transfer Protocol | IETF RFC 2821: Simple Mail Transfer Protocol | http://www.ietf.org/rfc/rfc2821.txt |
| RFC 2822:Internet Message Format | IETF RFC 2822: Internet Message Format | http://www.ietf.org/rfc/rfc2822.txt |
| RFC 791:Internet Protocol | IETF RFC 791: Internet Protocol Specification | http://www.ietf.org/rfc/rfc791.txt |
| RPM Package Format | RPM Package Format V3.0 | http://www.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html |
| SUSv2 Commands and Utilities | The Single UNIX Specification(SUS) Version 2, Commands and Utilities (XCU), Issue 5 (ISBN: 1-85912-191-8, C604) | http://www.opengroup.org/publications/catalog/un.htm |
| zlib Manual | zlib 1.2 Manual | http://www.gzip.org/zlib/ |
The libraries listed in Table 3-1 shall
be available on x86-64 Linux Standard Base systems, with the specified
runtime names. These names override or supplement the names specified
in the generic LSB (ISO/IEC 23360 Part 1) specification. The specified program interpreter,
referred to as proginterp in this table,
shall be used to load the shared libraries specified by
DT_NEEDED entries at run time.
Table 3-1. Standard Library Names
These libraries will be in an implementation-defined directory which the dynamic linker shall search by default.
A conforming implementation is necessarily architecture specific, and must provide the interfaces specified by both the generic LSB Core specification (ISO/IEC 23360 Part 1) and the relevant architecture specific part of ISO/IEC 23360.
Rationale: An implementation must provide at least the interfaces specified in these specifications. It may also provide additional interfaces.
A conforming implementation shall satisfy the following requirements:
A processor architecture represents a family of related processors which may not have identical feature sets. The architecture specific parts of ISO/IEC 23360 that supplement this specification for a given target processor architecture describe a minimum acceptable processor. The implementation shall provide all features of this processor, whether in hardware or through emulation transparent to the application.
The implementation shall be capable of executing compiled applications having the format 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 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 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 format 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.
A conforming application is necessarily architecture specific, and must conform to both the generic LSB Core specification (ISO/IEC 23360 Part 1)and the relevant architecture specific part of ISO/IEC 23360.
A conforming application shall satisfy the following requirements:
Its executable files shall be either shell scripts or object files in the format defined for the Object File Format system interface.
Its object files shall participate in dynamic linking as defined in the Program Loading and Linking System interface.
It shall employ 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 shall be stated in the application's documentation.
It shall not use any interface or data format that is not required to be provided by a conforming implementation, unless:
If such an interface or data format is supplied by another application through direct invocation of that application during execution, that application shall be in turn an LSB conforming application.
The use of that interface or data format, as well as its source, shall be identified in the documentation of the application.
It shall not use any values for a named interface that are reserved for vendor extensions.
For the purposes of this document, the following definitions, as specified in the ISO/IEC Directives, Part 2, 2001, 4th Edition, apply:
For the purposes of this document, the following terms apply:
The architectural part of the LSB Specification which describes the specific parts of the interface that are platform specific. The archLSB is complementary to the gLSB.
The total set of interfaces that are available to be used in the compiled binary code of a conforming application.
The common part of the LSB Specification that describes those parts of the interface that remain constant across all hardware implementations of the LSB.
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.
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.
The set of interfaces that are available to be used in the source code of a conforming application.
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.
Other terms and definitions used in this document shall have the same meaning as defined in Chapter 3 of the Base Definitions volume of ISO POSIX (2003).
Throughout this document, the following typographic conventions are used:
| function() | the name of a function | |
| command | the name of a command or utility | |
CONSTANT | a constant value | |
| parameter | a parameter | |
variable | a variable |
Throughout this specification, several tables of interfaces are presented. Each entry in these tables has the following format:
| name | the name of the interface | |
| (symver) | An optional symbol version identifier, if required. | |
| [refno] | A reference number indexing the table of referenced specifications that follows this table. |
For example,
refers to the interface named forkpty() with symbol versionGLIBC_2.0 that is defined in the
SUSv3 reference.
Note: Symbol versions are defined in the architecture specific parts of ISO/IEC 23360 only.
Executable and Linking Format (ELF) defines the object format for compiled applications. This specification supplements the information found in System V ABI Update and System V Application Binary Interface AMD64 Architecture Processor Supplement, and is intended to document additions made since the publication of that document.
The AMD64 Architecture is specified by the following documents
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. In particular, applications should not rely on the availability of the 3DNow!™ technology. In addition, a conforming application shall not use any instruction from Table 8-1.
Note: While this specification carries the attribution "AMD64", it is intended to apply to the entire x86_64 set of processors, including those based on Intel® 64 Architecture. However, this specification defers to the AMD64 architecture specifications listed above.
Conforming applications may use only instructions which do not require elevated privileges.
Conforming applications shall not invoke the implementations underlying system call interface directly. The interfaces in the implementation base libraries shall be used instead.
Rationale: Implementation-supplied base libraries may use the system call interface but applications must not assume any particular operating system or kernel version is 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 Section 3.1.2 of System V Application Binary Interface AMD64 Architecture Processor Supplement.
Note: The System V Application Binary Interface AMD64 Architecture Processor Supplement specification is itself layered on top of the System V Application Binary Interface - Intel386™ Architecture Processor Supplement.
LSB-conforming applications shall use the byte ordering defined in Section 3.1.2 of System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications shall use only the fundamental types described in Section 3.1.2 of System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications shall use alignment for aggregates and unions as described in Section 3.1.2 of System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications utilizing bit-fields shall follow the requirements of Section 3.1.2 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications shall use only the following features of the function calling sequence as defined in Section 3.2 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications shall use only the registers described in Section 3.2.1 (Registers and the Stack Frame) of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications shall use only the floating point registers described in Section 3.2.1 (Registers and the Stack Frame) of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications shall use stack frames as described in Section 3.2.2 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications shall pass parameters to functions as described in Section 3.2.3 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
Values are returned from functions as described in Section 3.3.2 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications shall use only the following features of the Operating System Interfaces as defined in Section 3.3 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
Synchronous and floating point or coprocessor exceptions shall behave as described in Section 3.3.1 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-Conforming applications shall use only the virtual address space described in Section 3.3.2 and 3.3.4 of the System V Application Binary Interface AMD64 Architecture Processor Supplement. Virtual memory page sizes shall be subject to the limitations described in Section 3.3.3 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications shall use only the following features of the Process Initialization as defined in Section 3.4 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
During process initialization, the special registers shall be initalized as described in Section 3.4.1 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
The process stack shall be initialized as described in Section 3.4.1 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
The auxiliary vector shall be initialized as described in Section 3.4.2 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications may use the coding examples given in Section 3.5 of the System V Application Binary Interface AMD64 Architecture Processor Supplement to guide implemention of fundamental operations in the following areas.
Section 3.5.1 of the System V Application Binary Interface AMD64 Architecture Processor Supplement describes a number of code models. LSB-Conforming applications may use any of these models except the Kernel and Large code models.
LSB-conforming applications may follow the position-independent function prologue example in Section 3.5.3 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications may follow the data objects examples in Section 3.5.4 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications may follow the function call examples in Section 3.5.5 of the System V Application Binary Interface AMD64 Architecture Processor Supplement. See Chapter 3 of System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming applications may follow the branching examples in Section 3.5.6 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-Conforming applications shall only use variable arguments to functions in the manner described in Section 3.5.7 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-Conforming applications may include DWARF debugging information. The DWARF Release Number and Register Number Mapping shall be as described in Section 3.6 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming implementations shall support the Executable and Linking Format (ELF) object file format, as defined by the System V ABI , System V ABI Update , System V Application Binary Interface AMD64 Architecture Processor Supplement and as supplemented by the generic LSB specification and ISO/IEC 23360 Part 1.
LSB-conforming applications shall identify the Machine Information as defined in Section 4.1.1 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
In addition to the requirements for ELF sections described in the generic LSB Core specification, conforming implementations shall support architecture specific sections as described below.
Note: The System V Application Binary Interface AMD64 Architecture Processor Supplement specifies some architecture specific section flags and section types that are not required by LSB-conforming systems.
The following architecture-specific sections are defined in the System V Application Binary Interface AMD64 Architecture Processor Supplement.
Table 9-1. ELF Special Sections
| 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. |
Note: Since LSB-conforming implementations are not required to support the large code model, it is not necessary for them to provide support for the additional special sections for the large code model described in the System V Application Binary Interface AMD64 Architecture Processor Supplement.
Also, the System V Application Binary Interface AMD64 Architecture Processor Supplement specifies a section .eh_frame, with a type of SHT_AMD64_UNWIND. This section is described in the generic LSB-Core specification, but with type SHT_PROGBITS. This specification does not require support for the SHT_AMD64_UNWIND section type.
The following additional sections are defined here.
Table 9-2. Additional Special Sections
| Name | Type | Attributes |
|---|---|---|
| .rela.dyn | SHT_RELA | SHF_ALLOC |
| .rela.plt | SHT_RELA | SHF_ALLOC |
LSB-conforming applications shall use Symbol Tables as defined in Section 4.3 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming implementation shall support the required relocation types defined in Section 4.4.1 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
Note: Since LSB-conforming implementations are not required to support the large code model, it is not necessary for them to provide support for the additional relocation types for the large code model described in the System V Application Binary Interface AMD64 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 ABI , System V ABI Update , System V Application Binary Interface AMD64 Architecture Processor Supplement and as supplemented by the generic LSB specification and ISO/IEC 23360 Part 1.
LSB-conforming implementations are not required to support the additional types and flags for this architecture as defined in Section 5.1 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
Note: The System V Application Binary Interface AMD64 Architecture Processor Supplement specification is itself layered on top of the System V Application Binary Interface - Intel386™ Architecture Processor Supplement. As such, the requirements of that specification are still requirements of this specification.
LSB-conforming implementations shall map file pages to virtual memory pages as described in Section 5.1 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming implementations shall provide dynamic linking as specified in Section 5.2 of the System V Application Binary Interface AMD64 Architecture Processor Supplement, except as described in the following sections.
Note: Since LSB-conforming implementations are not required to support the large model, support for dynamic linking of large model code is not required.
Dynamic section entries give information to the dynamic linker. The following dynamic entry types shall be supported:
LSB-conforming implementations shall support a Global Offset Table as described in Section 5.2 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
Function addresses shall behave as described in Section 5.2 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming implementations shall support a Procedure Linkage Table as described in Section 5.2 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
LSB-conforming implementations shall support initialization and termination functions as specified in Section 5.2.2 of the System V Application Binary Interface AMD64 Architecture Processor Supplement.
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 AMD64 platform are defined here. This section should be used in conjunction with the corresponding section in the Linux Standard Base Specification.
Table 11-1 defines the library name and shared object name for the libc library
The behavior of the interfaces in this library is specified by the following specifications:
| [LFS] Large File Support |
| [LSB] ISO/IEC 23360 Part 1 |
| [SUSv2] SUSv2 |
| [SUSv3] ISO POSIX (2003) |
| [SVID.3] SVID Issue 3 |
| [SVID.4] SVID Issue 4 |
An LSB conforming implementation shall provide the architecture specific functions for RPC specified in Table 11-2, with the full mandatory functionality as described in the referenced underlying specification.
Table 11-2. libc - RPC Function Interfaces
| authnone_create(GLIBC_2.2.5) [SVID.4] | clnt_create(GLIBC_2.2.5) [SVID.4] | clnt_pcreateerror(GLIBC_2.2.5) [SVID.4] | clnt_perrno(GLIBC_2.2.5) [SVID.4] |
| clnt_perror(GLIBC_2.2.5) [SVID.4] | clnt_spcreateerror(GLIBC_2.2.5) [SVID.4] | clnt_sperrno(GLIBC_2.2.5) [SVID.4] | clnt_sperror(GLIBC_2.2.5) [SVID.4] |
| key_decryptsession(GLIBC_2.2.5) [SVID.3] | pmap_getport(GLIBC_2.2.5) [LSB] | pmap_set(GLIBC_2.2.5) [LSB] | pmap_unset(GLIBC_2.2.5) [LSB] |
| svc_getreqset(GLIBC_2.2.5) [SVID.3] | svc_register(GLIBC_2.2.5) [LSB] | svc_run(GLIBC_2.2.5) [LSB] | svc_sendreply(GLIBC_2.2.5) [LSB] |
| svcerr_auth(GLIBC_2.2.5) [SVID.3] | svcerr_decode(GLIBC_2.2.5) [SVID.3] | svcerr_noproc(GLIBC_2.2.5) [SVID.3] | svcerr_noprog(GLIBC_2.2.5) [SVID.3] |
| svcerr_progvers(GLIBC_2.2.5) [SVID.3] | svcerr_systemerr(GLIBC_2.2.5) [SVID.3] | svcerr_weakauth(GLIBC_2.2.5) [SVID.3] | svctcp_create(GLIBC_2.2.5) [LSB] |
| svcudp_create(GLIBC_2.2.5) [LSB] | xdr_accepted_reply(GLIBC_2.2.5) [SVID.3] | xdr_array(GLIBC_2.2.5) [SVID.3] | xdr_bool(GLIBC_2.2.5) [SVID.3] |
| xdr_bytes(GLIBC_2.2.5) [SVID.3] | xdr_callhdr(GLIBC_2.2.5) [SVID.3] | xdr_callmsg(GLIBC_2.2.5) [SVID.3] | xdr_char(GLIBC_2.2.5) [SVID.3] |
| xdr_double(GLIBC_2.2.5) [SVID.3] | xdr_enum(GLIBC_2.2.5) [SVID.3] | xdr_float(GLIBC_2.2.5) [SVID.3] | xdr_free(GLIBC_2.2.5) [SVID.3] |
| xdr_int(GLIBC_2.2.5) [SVID.3] | xdr_long(GLIBC_2.2.5) [SVID.3] | xdr_opaque(GLIBC_2.2.5) [SVID.3] | xdr_opaque_auth(GLIBC_2.2.5) [SVID.3] |
| xdr_pointer(GLIBC_2.2.5) [SVID.3] | xdr_reference(GLIBC_2.2.5) [SVID.3] | xdr_rejected_reply(GLIBC_2.2.5) [SVID.3] | xdr_replymsg(GLIBC_2.2.5) [SVID.3] |
| xdr_short(GLIBC_2.2.5) [SVID.3] | xdr_string(GLIBC_2.2.5) [SVID.3] | xdr_u_char(GLIBC_2.2.5) [SVID.3] | xdr_u_int(GLIBC_2.2.5) [LSB] |
| xdr_u_long(GLIBC_2.2.5) [SVID.3] | xdr_u_short(GLIBC_2.2.5) [SVID.3] | xdr_union(GLIBC_2.2.5) [SVID.3] | xdr_vector(GLIBC_2.2.5) [SVID.3] |
| xdr_void(GLIBC_2.2.5) [SVID.3] | xdr_wrapstring(GLIBC_2.2.5) [SVID.3] | xdrmem_create(GLIBC_2.2.5) [SVID.3] | xdrrec_create(GLIBC_2.2.5) [SVID.3] |
| xdrrec_eof(GLIBC_2.2.5) [SVID.3] | xdrstdio_create(GLIBC_2.2.5) [LSB] |
An LSB conforming implementation shall provide the architecture specific functions for System Calls specified in Table 11-3, with the full mandatory functionality as described in the referenced underlying specification.
Table 11-3. libc - System Calls Function Interfaces
| __fxstat(GLIBC_2.2.5) [LSB] | __getpgid(GLIBC_2.2.5) [LSB] | __lxstat(GLIBC_2.2.5) [LSB] | __xmknod(GLIBC_2.2.5) [LSB] |
| __xstat(GLIBC_2.2.5) [LSB] | access(GLIBC_2.2.5) [SUSv3] | acct(GLIBC_2.2.5) [LSB] | alarm(GLIBC_2.2.5) [SUSv3] |
| brk(GLIBC_2.2.5) [SUSv2] | chdir(GLIBC_2.2.5) [SUSv3] | chmod(GLIBC_2.2.5) [SUSv3] | chown(GLIBC_2.2.5) [SUSv3] |
| chroot(GLIBC_2.2.5) [SUSv2] | clock(GLIBC_2.2.5) [SUSv3] | close(GLIBC_2.2.5) [SUSv3] | closedir(GLIBC_2.2.5) [SUSv3] |
| creat(GLIBC_2.2.5) [SUSv3] | dup(GLIBC_2.2.5) [SUSv3] | dup2(GLIBC_2.2.5) [SUSv3] | execl(GLIBC_2.2.5) [SUSv3] |
| execle(GLIBC_2.2.5) [SUSv3] | execlp(GLIBC_2.2.5) [SUSv3] | execv(GLIBC_2.2.5) [SUSv3] | execve(GLIBC_2.2.5) [SUSv3] |
| execvp(GLIBC_2.2.5) [SUSv3] | exit(GLIBC_2.2.5) [SUSv3] | fchdir(GLIBC_2.2.5) [SUSv3] | fchmod(GLIBC_2.2.5) [SUSv3] |
| fchown(GLIBC_2.2.5) [SUSv3] | fcntl(GLIBC_2.2.5) [LSB] | fdatasync(GLIBC_2.2.5) [SUSv3] | flock(GLIBC_2.2.5) [LSB] |
| fork(GLIBC_2.2.5) [SUSv3] | fstatfs(GLIBC_2.2.5) [LSB] | fstatvfs(GLIBC_2.2.5) [SUSv3] | fsync(GLIBC_2.2.5) [SUSv3] |
| ftime(GLIBC_2.2.5) [SUSv3] | ftruncate(GLIBC_2.2.5) [SUSv3] | getcontext(GLIBC_2.2.5) [SUSv3] | getdtablesize(GLIBC_2.2.5) [LSB] |
| getegid(GLIBC_2.2.5) [SUSv3] | geteuid(GLIBC_2.2.5) [SUSv3] | getgid(GLIBC_2.2.5) [SUSv3] | getgroups(GLIBC_2.2.5) [SUSv3] |
| getitimer(GLIBC_2.2.5) [SUSv3] | getloadavg(GLIBC_2.2.5) [LSB] | getpagesize(GLIBC_2.2.5) [LSB] | getpgid(GLIBC_2.2.5) [SUSv3] |
| getpgrp(GLIBC_2.2.5) [SUSv3] | getpid(GLIBC_2.2.5) [SUSv3] | getppid(GLIBC_2.2.5) [SUSv3] | getpriority(GLIBC_2.2.5) [SUSv3] |
| getrlimit(GLIBC_2.2.5) [SUSv3] | getrusage(GLIBC_2.2.5) [SUSv3] | getsid(GLIBC_2.2.5) [SUSv3] | getuid(GLIBC_2.2.5) [SUSv3] |
| getwd(GLIBC_2.2.5) [SUSv3] | initgroups(GLIBC_2.2.5) [LSB] | ioctl(GLIBC_2.2.5) [LSB] | kill(GLIBC_2.2.5) [LSB] |
| killpg(GLIBC_2.2.5) [SUSv3] | lchown(GLIBC_2.2.5) [SUSv3] | link(GLIBC_2.2.5) [LSB] | lockf(GLIBC_2.2.5) [SUSv3] |
| lseek(GLIBC_2.2.5) [SUSv3] | mkdir(GLIBC_2.2.5) [SUSv3] | mkfifo(GLIBC_2.2.5) [SUSv3] | mlock(GLIBC_2.2.5) [SUSv3] |
| mlockall(GLIBC_2.2.5) [SUSv3] | mmap(GLIBC_2.2.5) [SUSv3] | mprotect(GLIBC_2.2.5) [SUSv3] | mremap(GLIBC_2.2.5) [LSB] |
| msync(GLIBC_2.2.5) [SUSv3] | munlock(GLIBC_2.2.5) [SUSv3] | munlockall(GLIBC_2.2.5) [SUSv3] | munmap(GLIBC_2.2.5) [SUSv3] |
| nanosleep(GLIBC_2.2.5) [SUSv3] | nice(GLIBC_2.2.5) [SUSv3] | open(GLIBC_2.2.5) [SUSv3] | opendir(GLIBC_2.2.5) [SUSv3] |
| pathconf(GLIBC_2.2.5) [SUSv3] | pause(GLIBC_2.2.5) [SUSv3] | pipe(GLIBC_2.2.5) [SUSv3] | poll(GLIBC_2.2.5) [SUSv3] |
| pselect(GLIBC_2.2.5) [SUSv3] | read(GLIBC_2.2.5) [SUSv3] | readdir(GLIBC_2.2.5) [SUSv3] | readdir_r(GLIBC_2.2.5) [SUSv3] |
| readlink(GLIBC_2.2.5) [SUSv3] | readv(GLIBC_2.2.5) [SUSv3] | rename(GLIBC_2.2.5) [SUSv3] | rmdir(GLIBC_2.2.5) [SUSv3] |
| sbrk(GLIBC_2.2.5) [SUSv2] | sched_get_priority_max(GLIBC_2.2.5) [SUSv3] | sched_get_priority_min(GLIBC_2.2.5) [SUSv3] | sched_getparam(GLIBC_2.2.5) [SUSv3] |
| sched_getscheduler(GLIBC_2.2.5) [SUSv3] | sched_rr_get_interval(GLIBC_2.2.5) [SUSv3] | sched_setparam(GLIBC_2.2.5) [SUSv3] | sched_setscheduler(GLIBC_2.2.5) [LSB] |
| sched_yield(GLIBC_2.2.5) [SUSv3] | select(GLIBC_2.2.5) [SUSv3] | setcontext(GLIBC_2.2.5) [SUSv3] | setegid(GLIBC_2.2.5) [SUSv3] |
| seteuid(GLIBC_2.2.5) [SUSv3] | setgid(GLIBC_2.2.5) [SUSv3] | setitimer(GLIBC_2.2.5) [SUSv3] | setpgid(GLIBC_2.2.5) [SUSv3] |
| setpgrp(GLIBC_2.2.5) [SUSv3] | setpriority(GLIBC_2.2.5) [SUSv3] | setregid(GLIBC_2.2.5) [SUSv3] | setreuid(GLIBC_2.2.5) [SUSv3] |
| setrlimit(GLIBC_2.2.5) [SUSv3] | setrlimit64(GLIBC_2.2.5) [LFS] | setsid(GLIBC_2.2.5) [SUSv3] | setuid(GLIBC_2.2.5) [SUSv3] |
| sleep(GLIBC_2.2.5) [SUSv3] | statfs(GLIBC_2.2.5) [LSB] | statvfs(GLIBC_2.2.5) [SUSv3] | stime(GLIBC_2.2.5) [LSB] |
| symlink(GLIBC_2.2.5) [SUSv3] | sync(GLIBC_2.2.5) [SUSv3] | sysconf(GLIBC_2.2.5) [LSB] | time(GLIBC_2.2.5) [SUSv3] |
| times(GLIBC_2.2.5) [SUSv3] | truncate(GLIBC_2.2.5) [SUSv3] | ulimit(GLIBC_2.2.5) [SUSv3] | umask(GLIBC_2.2.5) [SUSv3] |
| uname(GLIBC_2.2.5) [SUSv3] | unlink(GLIBC_2.2.5) [LSB] | utime(GLIBC_2.2.5) [SUSv3] | utimes(GLIBC_2.2.5) [SUSv3] |
| vfork(GLIBC_2.2.5) [SUSv3] | wait(GLIBC_2.2.5) [SUSv3] | wait4(GLIBC_2.2.5) [LSB] | waitid(GLIBC_2.2.5) [SUSv3] |
| waitpid(GLIBC_2.2.5) [LSB] | write(GLIBC_2.2.5) [SUSv3] | writev(GLIBC_2.2.5) [SUSv3] |
An LSB conforming implementation shall provide the architecture specific deprecated functions for System Calls specified in Table 11-4, with the full mandatory functionality as described in the referenced underlying specification.
Note: These interfaces are deprecated, and applications should avoid using them. These interfaces may be withdrawn in future releases of this specification.
An LSB conforming implementation shall provide the architecture specific functions for Standard I/O specified in Table 11-5, with the full mandatory functionality as described in the referenced underlying specification.
Table 11-5. libc - Standard I/O Function Interfaces
| _IO_feof(GLIBC_2.2.5) [LSB] | _IO_getc(GLIBC_2.2.5) [LSB] | _IO_putc(GLIBC_2.2.5) [LSB] | _IO_puts(GLIBC_2.2.5) [LSB] |
| asprintf(GLIBC_2.2.5) [LSB] | clearerr(GLIBC_2.2.5) [SUSv3] | ctermid(GLIBC_2.2.5) [SUSv3] | fclose(GLIBC_2.2.5) [SUSv3] |
| fdopen(GLIBC_2.2.5) [SUSv3] | feof(GLIBC_2.2.5) [SUSv3] | ferror(GLIBC_2.2.5) [SUSv3] | fflush(GLIBC_2.2.5) [SUSv3] |
| fflush_unlocked(GLIBC_2.2.5) [LSB] | fgetc(GLIBC_2.2.5) [SUSv3] | fgetpos(GLIBC_2.2.5) [SUSv3] | fgets(GLIBC_2.2.5) [SUSv3] |
| fgetwc_unlocked(GLIBC_2.2.5) [LSB] | fileno(GLIBC_2.2.5) [SUSv3] | flockfile(GLIBC_2.2.5) [SUSv3] | fopen(GLIBC_2.2.5) [SUSv3] |
| fprintf(GLIBC_2.2.5) [SUSv3] | fputc(GLIBC_2.2.5) [SUSv3] | fputs(GLIBC_2.2.5) [SUSv3] | fread(GLIBC_2.2.5) [SUSv3] |
| freopen(GLIBC_2.2.5) [SUSv3] | fscanf(GLIBC_2.2.5) [LSB] | fseek(GLIBC_2.2.5) [SUSv3] | fseeko(GLIBC_2.2.5) [SUSv3] |
| fsetpos(GLIBC_2.2.5) [SUSv3] | ftell(GLIBC_2.2.5) [SUSv3] | ftello(GLIBC_2.2.5) [SUSv3] | fwrite(GLIBC_2.2.5) [SUSv3] |
| getc(GLIBC_2.2.5) [SUSv3] | getc_unlocked(GLIBC_2.2.5) [SUSv3] | getchar(GLIBC_2.2.5) [SUSv3] | getchar_unlocked(GLIBC_2.2.5) [SUSv3] |
| getw(GLIBC_2.2.5) [SUSv2] | pclose(GLIBC_2.2.5) [SUSv3] | popen(GLIBC_2.2.5) [SUSv3] | printf(GLIBC_2.2.5) [SUSv3] |
| putc(GLIBC_2.2.5) [SUSv3] | putc_unlocked(GLIBC_2.2.5) [SUSv3] | putchar(GLIBC_2.2.5) [SUSv3] | putchar_unlocked(GLIBC_2.2.5) [SUSv3] |
| puts(GLIBC_2.2.5) [SUSv3] | putw(GLIBC_2.2.5) [SUSv2] | remove(GLIBC_2.2.5) [SUSv3] | rewind(GLIBC_2.2.5) [SUSv3] |
| rewinddir(GLIBC_2.2.5) [SUSv3] | scanf(GLIBC_2.2.5) [LSB] | seekdir(GLIBC_2.2.5) [SUSv3] | setbuf(GLIBC_2.2.5) [SUSv3] |
| setbuffer(GLIBC_2.2.5) [LSB] | setvbuf(GLIBC_2.2.5) [SUSv3] | snprintf(GLIBC_2.2.5) [SUSv3] | sprintf(GLIBC_2.2.5) [SUSv3] |
| sscanf(GLIBC_2.2.5) [LSB] | telldir(GLIBC_2.2.5) [SUSv3] | tempnam(GLIBC_2.2.5) [SUSv3] | ungetc(GLIBC_2.2.5) [SUSv3] |
| vasprintf(GLIBC_2.2.5) [LSB] | vdprintf(GLIBC_2.2.5) [LSB] | vfprintf(GLIBC_2.2.5) [SUSv3] | vprintf(GLIBC_2.2.5) [SUSv3] |
| vsnprintf(GLIBC_2.2.5) [SUSv3] | vsprintf(GLIBC_2.2.5) [SUSv3] |
An LSB conforming implementation shall provide the architecture specific data interfaces for Standard I/O specified in Table 11-6, with the full mandatory functionality as described in the referenced underlying specification.
An LSB conforming implementation shall provide the architecture specific functions for Signal Handling specified in Table 11-7, with the full mandatory functionality as described in the referenced underlying specification.
Table 11-7. libc - Signal Handling Function Interfaces
| __libc_current_sigrtmax(GLIBC_2.2.5) [LSB] | __libc_current_sigrtmin(GLIBC_2.2.5) [LSB] | __sigsetjmp(GLIBC_2.2.5) [LSB] | __sysv_signal(GLIBC_2.2.5) [LSB] |
| __xpg_sigpause(GLIBC_2.2.5) [LSB] | bsd_signal(GLIBC_2.2.5) [SUSv3] | psignal(GLIBC_2.2.5) [LSB] | raise(GLIBC_2.2.5) [SUSv3] |
| sigaction(GLIBC_2.2.5) [SUSv3] | sigaddset(GLIBC_2.2.5) [SUSv3] | sigaltstack(GLIBC_2.2.5) [SUSv3] | sigandset(GLIBC_2.2.5) [LSB] |
| sigdelset(GLIBC_2.2.5) [SUSv3] | sigemptyset(GLIBC_2.2.5) [SUSv3] | sigfillset(GLIBC_2.2.5) [SUSv3] | sighold(GLIBC_2.2.5) [SUSv3] |
| sigignore(GLIBC_2.2.5) [SUSv3] | siginterrupt(GLIBC_2.2.5) [SUSv3] | sigisemptyset(GLIBC_2.2.5) [LSB] | sigismember(GLIBC_2.2.5) [SUSv3] |
| siglongjmp(GLIBC_2.2.5) [SUSv3] | signal(GLIBC_2.2.5) [SUSv3] | sigorset(GLIBC_2.2.5) [LSB] | sigpause(GLIBC_2.2.5) [LSB] |
| sigpending(GLIBC_2.2.5) [SUSv3] | sigprocmask(GLIBC_2.2.5) [SUSv3] | sigqueue(GLIBC_2.2.5) [SUSv3] | sigrelse(GLIBC_2.2.5) [SUSv3] |
| sigreturn(GLIBC_2.2.5) [LSB] | sigset(GLIBC_2.2.5) [SUSv3] | sigsuspend(GLIBC_2.2.5) [SUSv3] | sigtimedwait(GLIBC_2.2.5) [SUSv3] |
| sigwait(GLIBC_2.2.5) [SUSv3] | sigwaitinfo(GLIBC_2.2.5) [SUSv3] |
An LSB conforming implementation shall provide the architecture specific deprecated functions for Signal Handling specified in Table 11-8, with the full mandatory functionality as described in the referenced underlying specification.
Note: These interfaces are deprecated, and applications should avoid using them. These interfaces may be withdrawn in future releases of this specification.
An LSB conforming implementation shall provide the architecture specific data interfaces for Signal Handling specified in Table 11-9, with the full mandatory functionality as described in the referenced underlying specification.
An LSB conforming implementation shall provide the architecture specific functions for Localization Functions specified in Table 11-10, with the full mandatory functionality as described in the referenced underlying specification.
Table 11-10. libc - Localization Functions Function Interfaces
| bind_textdomain_codeset(GLIBC_2.2.5) [LSB] | bindtextdomain(GLIBC_2.2.5) [LSB] | catclose(GLIBC_2.2.5) [SUSv3] | catgets(GLIBC_2.2.5) [SUSv3] |
| catopen(GLIBC_2.2.5) [SUSv3] | dcgettext(GLIBC_2.2.5) [LSB] | dcngettext(GLIBC_2.2.5) [LSB] | dgettext(GLIBC_2.2.5) [LSB] |
| dngettext(GLIBC_2.2.5) [LSB] | gettext(GLIBC_2.2.5) [LSB] | iconv(GLIBC_2.2.5) [SUSv3] | iconv_close(GLIBC_2.2.5) [SUSv3] |
| iconv_open(GLIBC_2.2.5) [SUSv3] | localeconv(GLIBC_2.2.5) [SUSv3] | ngettext(GLIBC_2.2.5) [LSB] | nl_langinfo(GLIBC_2.2.5) [SUSv3] |
| setlocale(GLIBC_2.2.5) [SUSv3] | textdomain(GLIBC_2.2.5) [LSB] |
An LSB conforming implementation shall provide the architecture specific data interfaces for Localization Functions specified in Table 11-11, with the full mandatory functionality as described in the referenced underlying specification.
An LSB conforming implementation shall provide the architecture specific functions for Posix Spawn Option specified in Table 11-12, with the full mandatory functionality as described in the referenced underlying specification.
Table 11-12. libc - Posix Spawn Option Function Interfaces
| posix_spawn(GLIBC_2.2.5) [SUSv3] | posix_spawn_file_actions_addclose(GLIBC_2.2.5) [SUSv3] | posix_spawn_file_actions_adddup2(GLIBC_2.2.5) [SUSv3] | posix_spawn_file_actions_addopen(GLIBC_2.2.5) [SUSv3] |
| posix_spawn_file_actions_destroy(GLIBC_2.2.5) [SUSv3] | posix_spawn_file_actions_init(GLIBC_2.2.5) [SUSv3] | posix_spawnattr_destroy(GLIBC_2.2.5) [SUSv3] | posix_spawnattr_getflags(GLIBC_2.2.5) [SUSv3] |
| posix_spawnattr_getpgroup(GLIBC_2.2.5) [SUSv3] | posix_spawnattr_getschedparam(GLIBC_2.2.5) [SUSv3] | posix_spawnattr_getschedpolicy(GLIBC_2.2.5) [SUSv3] | posix_spawnattr_getsigdefault(GLIBC_2.2.5) [SUSv3] |
| posix_spawnattr_getsigmask(GLIBC_2.2.5) [SUSv3] | posix_spawnattr_init(GLIBC_2.2.5) [SUSv3] | posix_spawnattr_setflags(GLIBC_2.2.5) [SUSv3] | posix_spawnattr_setpgroup(GLIBC_2.2.5) [SUSv3] |
| posix_spawnattr_setschedparam(GLIBC_2.2.5) [SUSv3] | posix_spawnattr_setschedpolicy(GLIBC_2.2.5) [SUSv3] | posix_spawnattr_setsigdefault(GLIBC_2.2.5) [SUSv3] | posix_spawnattr_setsigmask(GLIBC_2.2.5) [SUSv3] |
| posix_spawnp(GLIBC_2.2.5) [SUSv3] |
An LSB conforming implementation shall provide the architecture specific functions for Posix Advisory Option specified in Table 11-13, with the full mandatory functionality as described in the referenced underlying specification.
An LSB conforming implementation shall provide the architecture specific functions for Socket Interface specified in Table 11-14, with the full mandatory functionality as described in the referenced underlying specification.
Table 11-14. libc - Socket Interface Function Interfaces
| __h_errno_location(GLIBC_2.2.5) [LSB] | accept(GLIBC_2.2.5) [SUSv3] | bind(GLIBC_2.2.5) [SUSv3] | bindresvport(GLIBC_2.2.5) [LSB] |
| connect(GLIBC_2.2.5) [SUSv3] | gethostid(GLIBC_2.2.5) [SUSv3] | gethostname(GLIBC_2.2.5) [SUSv3] | getpeername(GLIBC_2.2.5) [SUSv3] |
| getsockname(GLIBC_2.2.5) [SUSv3] | getsockopt(GLIBC_2.2.5) [LSB] | if_freenameindex(GLIBC_2.2.5) [SUSv3] | if_indextoname(GLIBC_2.2.5) [SUSv3] |
| if_nameindex(GLIBC_2.2.5) [SUSv3] | if_nametoindex(GLIBC_2.2.5) [SUSv3] | listen(GLIBC_2.2.5) [SUSv3] | recv(GLIBC_2.2.5) [SUSv3] |
| recvfrom(GLIBC_2.2.5) [SUSv3] | recvmsg(GLIBC_2.2.5) [SUSv3] | send(GLIBC_2.2.5) [SUSv3] | sendmsg(GLIBC_2.2.5) [SUSv3] |
| sendto(GLIBC_2.2.5) [SUSv3] | setsockopt(GLIBC_2.2.5) [LSB] | shutdown(GLIBC_2.2.5) [SUSv3] | sockatmark(GLIBC_2.2.5) [SUSv3] |
| socket(GLIBC_2.2.5) [SUSv3] | socketpair(GLIBC_2.2.5) [SUSv3] |
An LSB conforming implementation shall provide the architecture specific data interfaces for Socket Interface specified in Table 11-15, with the full mandatory functionality as described in the referenced underlying specification.
An LSB conforming implementation shall provide the architecture specific functions for Wide Characters specified