Copyright © 2004 Free Standards Group
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 are 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
These excerpts are being used in accordance with their respective licenses.
Linux is a trademark of Linus Torvalds.
UNIX a registered trademark of the Open Group in the United States and other countries.
LSB is a trademark of the Free Standards Group in the USA and other countries.
AMD is a trademark of Advanced Micro Devices, Inc.
Intel and Itanium are registered trademarks and Intel386 is a trademarks of Intel Corporation.
OpenGL is a registered trademark of Silicon Graphics, Inc.
This is version 3.0Preview1 of the Linux Standard Base Core Specification. 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 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.
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") describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific specification ("LSB-arch") describing the parts of the interface that vary by processor architecture. Together, the LSB-generic 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.
The LSB-generic document shall be used in conjunction with an architecture-specific supplement. Whenever a section of the LSB-generic specification shall be supplemented by architecture-specific information, the LSB-generic document includes a reference to the architecture supplement. Architecture supplements 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 shall provide 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 Core module of the Linux Standards Base (LSB). This module provides the fundamental system interfaces, libraries, and runtime environment upon which all conforming applications and libraries depend.
Interfaces described in this module are mandatory except where explicitly listed otherwise. Core interfaces may be supplemented by other modules; all modules are built upon the core.
The specifications listed below are referenced in whole or in part by the Linux Standard Base. In this specification, where only a particular section of one of these references is identified, then the normative reference is to that section alone, and the rest of the referenced document is informative.
Table 2-1. Normative References
| Name | Title | URL |
|---|---|---|
| DWARF Debugging Information Format | DWARF Debugging Information Format, Revision 2.0.0 (July 27, 1993) | http://www.eagercon.com/dwarf/dwarf-2.0.0.pdf |
| Filesystem Hierarchy Standard | Filesystem Hierarchy Standard (FHS) 2.3 | http://www.pathname.com/fhs/ |
| Gdk 2.6.2 Reference Manual | Gdk 2.6.2 Reference Manual | http://www.gtk.org/api/2.6/gdk/index.html |
| Gdk-pixbuf 2.6.2 Reference Manual | Gdk-pixbuf 2.6.2 Reference Manual | http://www.gtk.org/api/2.6/gdk-pixbuf/index.html |
| Glib 2.6.2 Reference Manual | Glib 2.6.2 Reference Manual | http://www.gtk.org/api/2.6/glib/index.html |
| Gobject 2.6.2 Reference Manual | Gobject 2.6.2 Reference Manual | http://www.gtk.org/api/2.6/gobject/index.html |
| Gtk 2.6.2 Reference Manual | Gtk 2.6.2 Reference Manual | http://www.gtk.org/api/2.6/gtk/index.html |
| IEEE Std 754-1985 | IEEE Standard 754 for Binary Floating-Point Arithmetic | http://www.ieee.org/ |
| 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/ |
| 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 |
| Large File Support | Large File Support | http://www.UNIX-systems.org/version2/whatsnew/lfs20mar.html |
| Li18nux Globalization Specification | LI18NUX 2000 Globalization Specification, Version 1.0 with Amendment 4 | http://www.li18nux.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 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 |
| 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 |
| 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 |
| 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 |
| this specification | Linux Standard Base | http://www.linuxbase.org/spec/ |
| 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 |
The libraries listed in Table 3-1 shall be available on a Linux Standard Base system, with the specified runtime names. The libraries listed in Table 3-2 are architecture specific, but shall be available on all LSB conforming systems. This list may be supplemented or amended by the architecture-specific specification.
Table 3-1. Standard Library Names
| Library | Runtime Name |
|---|---|
| libdl | libdl.so.2 |
| libcrypt | libcrypt.so.1 |
| libz | libz.so.1 |
| libncurses | libncurses.so.5 |
| libutil | libutil.so.1 |
| libpthread | libpthread.so.0 |
| libpam | libpam.so.0 |
| libgcc_s | libgcc_s.so.1 |
Table 3-2. Standard Library Names defined in the Architecture Specific Supplement
| Library | Runtime Name |
|---|---|
| libm | See archLSB |
| libc | See archLSB |
| proginterp | See archLSB |
These libraries will be in an implementation-defined directory which the dynamic linker shall search by default.
A conforming implementation shall satisfy 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 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 shall satisfy the following requirements:
Its executable files are either shell scripts or object files in the format 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 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 is in turn an LSB conforming application.
The use of that interface or data format, as well as its source, is 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:
be able to; there is a possibility of; it is possible to
be unable to; there is no possibilty of; it is not possible to
is permitted; is allowed; is permissible
it is not required that; no...is required
is to; is required to; it is required that; has to; only...is permitted; it is necessary
is not allowed [permitted] [acceptable] [permissible]; is required to be not; is required that...be not; is not to be
it is recommended that; ought to
it is not recommended that; ought not to
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:
the name of a function
the name of a command or utility
CONSTANTa constant value
a parameter
variablea variable
Throughout this specification, several tables of interfaces are presented. Each entry in these tables has the following format:
the name of the interface
An optional symbol version identifier, if required.
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
first of the listed references below the table.This specification includes many interfaces described in ISO POSIX (2003). Unless otherwise specified, such interfaces should behave exactly as described in that specification. Any conflict between the requirements described here and the ISO POSIX (2003) standard is unintentional, except as explicitly noted otherwise.
Note: In addition to the differences noted inline in this specification, PDTR 24715 has extracted the differences between this specification and ISO POSIX (2003) into a single place. It is the long term plan of the LSB to converge with ISO/IEC 9945 POSIX.
The LSB Specification Authority is responsible for deciding the meaning of conformance to normative referenced standards in the LSB context. Problem Reports regarding underlying or referenced standards in any other context will be referred to the relevant maintenance body for that standard.
LSB-conforming applications shall assume that stack, heap and other allocated memory regions will be non-executable. The application must take steps to make them executable if needed.
LSB-conforming applications shall use the data representation as defined in the Arcitecture specific ELF documents.
In addition to the fundamental types specified in the Architecture specific ELF documents, a 1 byte data type is defined here.
LSB-conforming implementations shall support the object file Executable and Linking Format (ELF), which is defined by the following documents:
this document
an architecture-specific LSB specification
As described in System V ABI, an ELF object file contains a number of sections.
The section header table is an array of
Elf32_Shdr or
Elf64_Shdr structures as
described in System V ABI. The
sh_type member shall be either a value from
Table 4-1, drawn from the System V
ABI, or one of the additional values specified in Table 4-2.
A section header's sh_type member specifies the sections's semantics.
The following section types are defined in the System V ABI and the System V ABI Update.
Table 4-1. ELF Section Types
| Name | Value | Description |
|---|---|---|
| SHT_DYNAMIC | 0x6 | The section holds information for dynamic linking. Currently, an object file shall have only one dynamic section, but this restriction may be relaxed in the future. See `Dynamic Section' in Chapter 5 for details. |
| SHT_DYNSYM | 0xb | This section holds a minimal set of symbols adequate for dynamic linking. See also SHT_SYMTAB. Currently, an object file may have either a section of SHT_SYMTAB type or a section of SHT_DYNSYM type, but not both. This restriction may be relaxed in the future. |
| SHT_FINI_ARRAY | 0xf | This section contains an array of pointers to termination functions, as described in `Initialization and Termination Functions' in Chapter 5. Each pointer in the array is taken as a parameterless procedure with a void return. |
| SHT_HASH | 0x5 | The section holds a symbol hash table. Currently, an object file shall have only one hash table, but this restriction may be relaxed in the future. See `Hash Table' in the Chapter 5 for details. |
| SHT_HIPROC | 0x7fffffff | Values in this inclusive range are reserved for processor-specific semantics. |
| SHT_HIUSER | 0xffffffff | This value specifies the upper bound of the range of indexes reserved for application programs. Section types between SHT_LOUSER and SHT_HIUSER can be used by the application, without conflicting with current or future system-defined section types. |
| SHT_INIT_ARRAY | 0xe | This section contains an array of pointers to initialization functions, as described in `Initialization and Termination Functions' in Chapter 5. Each pointer in the array is taken as a parameterless procedure with a void return. |
| SHT_LOPROC | 0x70000000 | Values in this inclusive range are reserved for processor-specific semantics. |
| SHT_LOUSER | 0x80000000 | This value specifies the lower bound of the range of indexes reserved for application programs. |
| SHT_NOBITS | 0x8 | A section of this type occupies no space in the file but otherwise resembles SHT_PROGBITS. Although this section contains no bytes, the sh_offset member contains the conceptual file offset. |
| SHT_NOTE | 0x7 | The section holds information that marks the file in some way. See `Note Section' in Chapter 5 for details. |
| SHT_NULL | 0x0 | This value marks the section header as inactive; it does not have an associated section. Other members of the section header have undefined values. |
| SHT_PREINIT_ARRAY | 0x10 | This section contains an array of pointers to functions that are invoked before all other initialization functions, as described in `Initialization and Termination Functions' in Chapter 5. Each pointer in the array is taken as a parameterless proceure with a void return. |
| SHT_PROGBITS | 0x1 | The section holds information defined by the program, whose format and meaning are determined solely by the program. |
| SHT_REL | 0x9 | The section holds relocation entries without explicit addends, such as type Elf32_Rel for the 32-bit class of object files or type Elf64_Rel for the 64-bit class of object files. An object file may have multiple relocation sections. See "Relocation" |
| SHT_RELA | 0x4 | The section holds relocation entries with explicit addends, such as type Elf32_Rela for the 32-bit class of object files or type Elf64_Rela for the 64-bit class of object files. An object file may have multiple relocation sections. `Relocation' b |
| SHT_SHLIB | 0xa | This section type is reserved but has unspecified semantics. |
| SHT_STRTAB | 0x3 | The section holds a string table. An object file may have multiple string table sections. See `String Table' below for details. |
| SHT_SYMTAB | 0x2 | This section holds a symbol table. Currently, an object file may have either a section of SHT_SYMTAB type or a section of SHT_DYNSYM type, but not both. This restriction may be relaxed in the future. Typically, SHT_SYMTAB provides symbols for link editing, though it may also be used for dynamic linking. As a complete symbol table, it may contain many symbols unnecessary for dynamic linking. |
Various sections hold program and control information. Sections in the lists below are used by the system and have the indicated types and attributes.
The following sections are defined in the System V ABI and the System V ABI Update.
Table 5-1. ELF Special Sections
| Name | Type | Attributes |
|---|---|---|
| .bss | SHT_NOBITS | SHF_ALLOC+SHF_WRITE |
| .comment | SHT_PROGBITS | 0 |
| .data | SHT_PROGBITS | SHF_ALLOC+SHF_WRITE |
| .data1 | SHT_PROGBITS | SHF_ALLOC+SHF_WRITE |
| .debug | SHT_PROGBITS | 0 |
| .dynamic | SHT_DYNAMIC | SHF_ALLOC+SHF_WRITE |
| .dynstr | SHT_STRTAB | SHF_ALLOC |
| .dynsym | SHT_DYNSYM | SHF_ALLOC |
| .fini | SHT_PROGBITS | SHF_ALLOC+SHF_EXECINSTR |
| .fini_array | SHT_FINI_ARRAY | SHF_ALLOC+SHF_WRITE |
| .hash | SHT_HASH | SHF_ALLOC |
| .init | SHT_PROGBITS | SHF_ALLOC+SHF_EXECINSTR |
| .init_array | SHT_INIT_ARRAY | SHF_ALLOC+SHF_WRITE |
| .interp | SHT_PROGBITS | SHF_ALLOC |
| .line | SHT_PROGBITS | 0 |
| .note | SHT_NOTE | 0 |
| .preinit_array | SHT_PREINIT_ARRAY | SHF_ALLOC+SHF_WRITE |
| .rodata | SHT_PROGBITS | SHF_ALLOC |
| .rodata1 | SHT_PROGBITS | SHF_ALLOC |
| .shstrtab | SHT_STRTAB | 0 |
| .strtab | SHT_STRTAB | SHF_ALLOC |
| .symtab | SHT_SYMTAB | SHF_ALLOC |
| .tbss | SHT_NOBITS | SHF_ALLOC+SHF_WRITE+SHF_TLS |
| .tdata | SHT_PROGBITS | SHF_ALLOC+SHF_WRITE+SHF_TLS |
| .text | SHT_PROGBITS | SHF_ALLOC+SHF_EXECINSTR |
This section holds data that contributes to the program's memory image. The program may treat this data as uninitialized. However, the system shall initialize this data with zeroes when the program begins to run. The section occupies no file space, as indicated by the section type, SHT_NOBITS
This section holds version control information.
This section holds initialized data that contribute to the program's memory image.
This section holds initialized data that contribute to the program's memory image.
This section holds information for symbolic debugging. The contents are unspecified. All section names with the prefix .debug hold information for symbolic debugging. The contents of these sections are unspecified.
This section holds dynamic linking information. The section's attributes will include the SHF_ALLOC bit. Whether the SHF_WRITE bit is set is processor specific. See Chapter 5 for more information.
This section holds strings needed for dynamic linking, most commonly the strings that represent the names associated with symbol table entries. See Chapter 5 for more information.
This section holds the dynamic linking symbol table, as described in `Symbol Table'. See Chapter 5 for more information.
This section holds executable instructions that contribute to the process termination code. That is, when a program exits normally, the system arranges to execute the code in this section.
This section holds an array of function pointers that contributes to a single termination array for the executable or shared object containing the section.
This section holds a symbol hash table. See `Hash Table' in Chapter 5 for more information.
This section holds executable instructions that contribute to the process initialization code. When a program starts to run, the system arranges to execute the code in this section before calling the main program entry point (called main for C programs)
This section holds an array of function pointers that contributes to a single initialization array for the executable or shared object containing the section.
This section holds the path name of a program interpreter. If the file has a loadable segment that includes relocation, the sections' attributes will include the SHF_ALLOC bit; otherwise, that bit will be off. See Chapter 5 for more information.
This section holds line number information for symbolic debugging, which describes the correspondence between the source program and the machine code. The contents are unspecified.
This section holds information in the format that `Note Section' in Chapter 5 describes of the System V Application Binary Interface, Edition 4.1.
This section holds an array of function pointers that contributes to a single pre-initialization array for the executable or shared object containing the section.
This section holds read-only data that typically contribute to a non-writable segment in the process image. See `Program Header' in Chapter 5 for more information.
This section hold sread-only data that typically contribute to a non-writable segment in the process image. See `Program Header' in Chapter 5 for more information.
This section holds section names.
This section holds strings, most commonly the strings that represent the names associated with symbol table entries. If the file has a loadable segment that includes the symbol string table, the section's attributes will include the SHF_ALLOC bit; otherwi
This section holds a symbol table, as `Symbol Table'. in this chapter describes. If the file has a loadable segment that includes the symbol table, the section's attributes will include the SHF_ALLOC bit; otherwise, that bit will be off.
This section holds uninitialized thread-local data that contribute to the program's memory image. By definition, the system initializes the data with zeros when the data is instantiated for each new execution flow. The section occupies no file space, as indicated by the section type, SHT_NOBITS. Implementations need not support thread-local storage.
This section holds initialized thread-local data that contributes to the program's memory image. A copy of its contents is instantiated by the system for each new execution flow. Implementations need not support thread-local storage.
This section holds the `text,' or executable instructions, of a program.
Object files in an LSB conforming application may also contain one or more of the additional special sections described below.
Table 5-2. Additional Special Sections
| Name | Type | Attributes |
|---|---|---|
| .ctors | SHT_PROGBITS | SHF_ALLOC+SHF_WRITE |
| .dtors | SHT_PROGBITS | SHF_ALLOC+SHF_WRITE |
| .eh_frame | SHT_PROGBITS | SHF_ALLOC |
| .eh_frame_hdr | SHT_PROGBITS | SHF_ALLOC |
| .gnu.version | SHT_GNU_versym | SHF_ALLOC |
| .gnu.version_d | SHT_GNU_verdef | SHF_ALLOC |
| .gnu.version_r | SHT_GNU_verneed | SHF_ALLOC |
| .jcr | SHT_PROGBITS | SHF_ALLOC+SHF_WRITE |
| .note.ABI-tag | SHT_NOTE | SHF_ALLOC |
| .stab | SHT_PROGBITS | 0 |
| .stabstr | SHT_STRTAB | 0 |
This section contains a list of global constructor function pointers.
This section contains a list of global destructor function pointers.
This section contains information necessary for frame unwinding during exception handling.
This section contains a pointer to the .eh_frame section which is accessible to the runtime support code of a C++ application. This section may also contain a binary search table which may be used by the runtime support code to more efficiently access records in the .eh_frame section.
This section contains the Symbol Version Table.
This section contains the Version Definitions.
This section contains the Version Requirments.
This section contains information necessary for registering compiled Java classes. The contents are compiler-specific and used by compiler initialization functions.
Specify ABI details.
This section contains debugging information. The contents are not specified as part of the LSB.
This section contains strings associated with the debugging infomation contained in the .stab section.
This chapter defines how names are mapped from the source symbol to the object symbol.
Symbols in a source program are translated by the compilation system into symbols that exist in the object file. The rules for this translation are defined here.
In addition to the Call Frame Instructions defined in section 6.4.2 of DWARF Debugging Information Format, the following Call Frame Instructions may also be used.
Table 7-1. Additional DWARF Call Frame Instructions
| Name | Value | Meaning |
|---|---|---|
| DW_CFA_expression | 0x10 | The DW_CFA_expression instruction takes two operands: an unsigned LEB128 value representing a register number, and a DW_FORM_block value representing a DWARF expression. The required action is to establish the DWARF expression as the means by which the address in which the given register contents are found may be computed. The value of the CFA is pushed on the DWARF evaluation stack prior to execution of the DWARF expression. The DW_OP_call2, DW_OP_call4, DW_OP_call_ref and DW_OP_push_object_address DWARF operators (see Section 2.4.1 of DWARF Debugging Information Format) cannot be used in such a DWARF expression. |
| DW_CFA_offset_extended_sf | 0x11 | The DW_CFA_offset_extended_sf instruction takes two operands: an unsigned LEB128 value representing a register number and a signed LEB128 factored offset. This instruction is identical to DW_CFA_offset_extended except that the second operand is signed. |
| DW_CFA_def_cfa_sf | 0x12 | The DW_CFA_def_cfa_sf instruction takes two operands: an unsigned LEB128 value representing a register number and a signed LEB128 factored offset. This instruction is identical to DW_CFA_def_cfa except that the second operand is signed and factored. |
| DW_CFA_def_cfa_offset_sf | 0x13 | The DW_CFA_def_cfa_offset_sf instruction takes a signed LEB128 operand representing a factored offset. This instruction is identical to DW_CFA_def_cfa_offset except that the operand is signed and factored. |
| DW_CFA_GNU_args_size | 0x2e | The DW_CFA_def_cfa_offset_sf instruction takes an unsigned LEB128 operand representing an argument size. |
| DW_CFA_GNU_negative_offset_extended | 0x2f | The DW_CFA_def_cfa_sf instruction takes two operands: an unsigned LEB128 value representing a register number and an unsigned LEB128 which represents the magnitude of the offset. This instruction is identical to DW_CFA_offset_extended_sf except that the operand is subtracted to produce the offset. This instructions is obsoleted by DW_CFA_offset_extended_sf. |
This chapter will contain a formal description of the contents of the .eh_frame_hdr section.
The .eh_frame_hdr section contains additional information about the .eh_frame section. A pointer to the start of the .eh_frame data, and optionally, a binary search table of pointers to the .eh_frame records are found in this section.
Data in this section is encoded according to the DWARF Exception Header Encoding described below.
Table 9-1. .eh_frame_hdr Section Format
| Encoding | Field |
|---|---|
| unsigned byte | version |
| unsigned byte | eh_frame_ptr_enc |
| unsigned byte | fde_count_enc |
| unsigned byte | table_enc |
| encoded | eh_frame_ptr |
| encoded | fde_count |
| binary search table |
Version of the .eh_frame_hdr format. This value shall be 1.
The encoding format of the eh_frame_ptr field.
The encoding format of the fde_count field. A value of DW_EH_PE_omit indicates the binary search table is not present.
The encoding format of the entries in the binary search table. A value of DW_EH_PE_omit indicates the binary search table is not present.
The encoded value of the pointer to the start of the .eh_frame section.
The encoded value of the count of entries in the binary search table.
A binary search table containing fde_count entries. Each entry of the table consist of two encoded values, the initial location, and the address. The entries are sorted in an increasing order by the initial location value.
The DWARF Exception Header Encoding is used to describe the type of data used in the .eh_frame_hdr section. The upper 4 bits indicate how the value is to be applied. The lower 4 bits indicate the format of the data.
Table 9-2. DWARF Exception Header value format
| Name | Value | Meaning |
|---|---|---|
| DW_EH_PE_omit | 0xff | No value is present. |
| DW_EH_PE_uleb128 | 0x01 | Unsigned value is encoded using the Little Endian Base 128 (LEB128) as defined by DWARF Debugging Information Format. |
| DW_EH_PE_udata2 | 0x02 | A 2 bytes unsigned value. |
| DW_EH_PE_udata4 | 0x03 | A 4 bytes unsigned value. |
| DW_EH_PE_udata8 | 0x04 | An 8 bytes unsigned value. |
| DW_EH_PE_sleb128 | 0x09 | Signed value is encoded using the Little Endian Base 128 (LEB128) as defined by DWARF Debugging Information Format. |
| DW_EH_PE_sdata2 | 0x0A | A 2 bytes signed value. |
| DW_EH_PE_sdata4 | 0x0B | A 4 bytes signed value. |
| DW_EH_PE_sdata8 | 0x0C | An 8 bytes signed value. |
Table 9-3. DWARF Exception Header application
| Name | Value | Meaning |
|---|---|---|
| DW_EH_PE_absptr | 0x00 | Value is used with no modification. |
| DW_EH_PE_pcrel | 0x10 | Value is reletive to the current program counter. |
| DW_EH_PE_datarel | 0x30 | Value is reletive to the beginning of the .eh_frame_hdr section. |
| DW_EH_PE_omit | 0xff | No value is present. |
This chapter describes the Symbol Versioning mechanism. All ELF objects may provide or depend on versioned symbols. Symbol Versioning is implemented by 3 section types: SHT_GNU_versym, SHT_GNU_verdef, and SHT_GNU_verneed.
The prefix Elfxx in the following descriptions and code fragments stands for either "Elf32" or "Elf64", depending on the architecture.
Versions are described by strings. The structures that are used for symbol versions also contain a member that holds the ELF hashing values of the strings. This allows for more efficient processing.
The special section .gnu.version which has a section type of SHT_GNU_versym shall contain the Symbol Version Table. This section shall have the same number of entries as the Dynamic Symbol Table in the .dynsym section.
The .gnu.version section shall contain an array of elements of type Elfxx_Half. Each entry specifies the version defined for or required by the corresponding symbol in the Dynamic Symbol Table.
The values in the Symbol Version Table are specific to the object in which they
are located. These values are identifiers that are provided by the the
vna_other member of the
Elfxx_Vernaux structure or the
vd_ndx member of the
Elfxx_Verdef structure.
The values 0 and 1 are reserved.
The symbol is local, not available outside the object.
The symbol is defined in this object and is globally available.
All other values are used to identify version strings located in one of the other Symbol Version sections. The value itself is not the version associated with the symbol. The string identified by the value defines the version of the symbol.
Symbol definitions are contained in the special section .gnu.version_d which has a section type of SHT_GNU_verdef. The number of entries in this section is contained in the DT_VERDEFNUM entry of the Dynamic Section. The sh_link member of the section header points to the section that contains the strings referenced by this section.
The special section .gnu.version_d which has a section type of SHT_GNU_verdef shall contain symbol version definitions. The number of entries in this section shall be contained in the DT_VERDEFNUM entry of the Dynamic Section .dynamic. The sh_link member of the section header (see figure 4-8 in the System V ABI) shall point to the section that contains the strings referenced by this section.
The section shall contain an array of Elfxx_Verdef structures, as described in Figure 10-1, optionally followed by an array of Elfxx_Verdaux structures, as defined in Figure 10-2.
typedef struct {
Elfxx_Half vd_version;
Elfxx_Half vd_flags;
Elfxx_Half vd_ndx;
Elfxx_Half vd_cnt;
Elfxx_Word vd_hash;
Elfxx_Word vd_aux;
Elfxx_Word vd_next;
} Elfxx_Verdef; |
Figure 10-1. Version Definition Entries
vd_versionVersion revision. This field shall be set to 1.
vd_flagsVersion information flag bitmask.
vd_ndxVersion index numeric value referencing the SHT_GNU_versym section.
vd_cntNumber of associated verdaux array entries.
vd_hashVersion name hash value (ELF hash function).
vd_auxOffset in bytes to a corresponding entry in an array of Elfxx_Verdaux structures as defined in Figure 10-2
vd_nextOffset to the next verdef entry, in bytes.
typedef struct {
Elfxx_Word vda_name;
Elfxx_Word vda_next;
} Elfxx_Verdaux; |
Figure 10-2. Version Definition Auxiliary Entries
vda_nameOffset to the version or dependency name string in the section header, in bytes.
vda_nextOffset to the next verdaux entry, in bytes.
The special section .gnu.version_r which has a section type of
SHT_GNU_verneed
shall contain required symbol version definitions. The number of entries in
this section shall be contained in the DT_VERNEEDNUM entry of the Dynamic
Section .dynamic.
The sh_link member of the section header (see figure 4-8 in
System V ABI)
shall point to the section that contains the strings referenced by this section.
The section shall contain an array of Elfxx_Verneed structures, as described in Figure 10-3, optionally followed by an array of Elfxx_Vernaux structures, as defined in Figure 10-4.
typedef struct {
Elfxx_Half vn_version;
Elfxx_Half vn_cnt;
Elfxx_Word vn_file;
Elfxx_Word vn_aux;
Elfxx_Word vn_next;
} Elfxx_Verneed; |
Figure 10-3. Version Needed Entries
vn_versionVersion of structure. This value is currently set to 1, and will be reset if the versioning implementation is incompatibly altered.
vn_cntNumber of associated verneed array entries.
vn_fileOffset to the file name string in the section header, in bytes.
vn_auxOffset to a corresponding entry in the vernaux array, in bytes.
vn_nextOffset to the next verneed entry, in bytes.
typedef struct {
Elfxx_Word vna_hash;
Elfxx_Half vna_flags;
Elfxx_Half vna_other;
Elfxx_Word vna_name;
Elfxx_Word vna_next;
} Elfxx_Vernaux; |
Figure 10-4. Version Needed Auxiliary Entries
vna_hashDependency name hash value (ELF hash function).
vna_flagsDependency information flag bitmask.
vna_otherObject file version identifier used in the .gnu.version symbol version array. Bit number 15 controls whether or not the object is hidden; if this bit is set, the object cannot be used and the static linker will ignore the symbol's presence in the object.
vna_nameOffset to the dependency name string in the section header, in bytes.
vna_nextOffset to the next vernaux entry, in bytes.
When loading a sharable object the system shall analyze version definition data from the loaded object to assure that it meets the version requirements of the calling object. This step is referred to as definition testing. The dynamic loader shall retrieve the entries in the caller's Elfxx_Verneed array and attempt to find matching definition information in the loaded Elfxx_Verdef table.
Each object and dependency shall be tested in turn. If a symbol definition is missing and the vna_flags bit for VER_FLG_WEAK is not set, the loader shall return an error and exit. If the vna_flags bit for VER_FLG_WEAK is set in the Elfxx_Vernaux entry, and the loader shall issue a warning and continue operation.
When the versions referenced by undefined symbols in the loaded object are found, version availability is certified. The test completes without error and the object shall be made available.
When symbol versioning is used in an object, relocations extend definition testing beyond the simple match of symbol name strings: the version of the reference shall also equal the name of the definition.
The same index that is used in the symbol table can be referenced in the SHT_GNU_versym section, and the value of this index is then used to acquire name data. The corresponding requirement string is retrieved from the Elfxx_Verneed array, and likewise, the corresponding definition string from the Elfxx_Verdef table.
If the high order bit (bit number 15) of the version symbolis set, the object cannot be used and the static linker shall ignore the symbol's presence in the object.
When an object with a reference and an object with the definition are being linked, the following rules shall govern the result:
The object with the reference and the object with the definitions both use
versioning. All described matching is processed in this case. A fatal error
shall be triggered when no matching definition can be found in the object whose
name is the one referenced by the vn_name element in the
Elfxx_Verneed entry.
The object with the reference does not use versioning, while the object with the definitions does. In this instance, only the definitions with index numbers 1 and 2 will be used in the reference match, the same identified by the static linker as the base definition. In cases where the static linker was not used, such as in calls to dlopen(), a version that does not have the base definition index shall be acceptable if it is the only version for which the symbol is defined.
The object with the reference uses versioning, but the object with the definitions specifies none. A matching symbol shall be accepted in this case. A fatal error shall be triggered if a corruption in the required symbols list obscures an outdated object file and causes a match on the object filename in the Elfxx_Verneed entry.
Neither the object with the reference nor the object with the definitions use versioning. The behavior in this instance shall default to pre-existing symbol rules.
Every executable shall contain a section named .note.ABI-tag of type SHT_NOTE. This section is structured as a note section as documented in the ELF spec. The section shall contain at least the following entry. The name field (namesz/name) contains the string "GNU". The type field shall be 1. The descsz field shall be at least 16, and the first 16 bytes of the desc field shall be as follows.
The first 32-bit word of the desc field shall be 0 (this signifies a Linux executable). The second, third, and fourth 32-bit words of the desc field contain the earliest compatible kernel version. For example, if the 3 words are 2, 2, and 5, this signifies a 2.2.5 kernel.
LSB-conforming implementations shall support the object file information and system actions that create running programs as specified in the System V ABI and System V ABI Update and as supplemented by this document and an architecture-specific LSB specification.
Any shared object that is loaded shall contain sufficient DT_NEEDED records to satisfy the symbols on the shared library.
In addition to the Segment Types defined in the System V ABI and System V ABI Update the following Segment Types shall also be supported.
The array element specifies the location and size of the exception handling information as defined by the .eh_frame_hdr section.
The p_flags member specifies the permissions on the segment containing the stack
and is used to indicate wether the stack should be executable. The absense of
this header indicates that the stack will be executable.
As described in System V ABI, if an object file participates in dynamic linking, its program header table shall have an element of type PT_DYNAMIC. This `segment' contains the .dynamic section. A special symbol, _DYNAMIC, labels the section, which contains an array of the following structures.
typedef struct {
Elf32_Sword d_tag;
union {
Elf32_Word d_val;
Elf32_Addr d_ptr;
} d_un;
} Elf32_Dyn;
extern Elf32_Dyn _DYNAMIC[];
typedef struct {
Elf64_Sxword d_tag;
union {
Elf64_Xword d_val;
Elf64_Addr d_ptr;
} d_un;
} Elf64_Dyn;
extern Elf64_Dyn _DYNAMIC[]; |
Figure 14-1. Dynamic Structure
For each object with this type, d_tag
controls the interpretation of d_un.
The following dynamic entries are defined in the System V ABI and System V ABI Update.
Process relocations of object
For debugging; unspecified
Address of termination function
Address of symbol hash table
End of processor-specific
Address of init function
Address of PLT relocs
Start of processor-specific
Name of needed library
Marks end of dynamic section
Type of reloc in PLT
Size in bytes of PLT relocs
Address of Rel relocs
Address of Rela relocs
Size of one Rela reloc
Total size of Rela relocs
Size of one Rel reloc
Total size of Rel relocs
Library search path
Name of shared object
Size of string table
Address of string table
Start symbol search here
Size of one symbol table entry
Address of symbol table
Reloc might modify .text
An LSB conforming object may also use the following additional Dynamic Entry types.
Values from DT_ADDRRNGLO through DT_ADDRRNGHI are reserved for definition by an archLSB.
Values from DT_ADDRRNGLO through DT_ADDRRNGHI are reserved for definition by an archLSB.
Shared object to load before self
Shared object to get values from
The address of an array of pointers to termination functions.
Size in bytes of DT_FINI_ARRAY
Values from DT_LOOS through DT_HIOS are reserved for definition by specific operating systems.
The address of an array of pointers to initialization functions.
Size in bytes of DT_INIT_ARRAY
Values from DT_LOOS through DT_HIOS are reserved for definition by specific operating systems.
Number of dynamic entry tags defined (excepting reserved ranges).
Flags for DT_* entries, effecting the following DT_* entry
All Elf32_Rel R_*_RELATIVE relocations have been placed into a single block and this entry specifies the number of entries in that block. This permits ld.so.1 to streamline the processing of RELATIVE relocations.
null-terminated library search path string
Entry size of syminfo
Address of the Syminfo table.
Size of syminfo table (in bytes)
Entries which fall between DT_VALRNGHI & DT_VALRNGLO use the Dyn.d_un.d_val field of the Elf*_Dyn structure.
Entries which fall between DT_VALRNGHI & DT_VALRNGLO use the Dyn.d_un.d_val field of the Elf*_Dyn structure.
Address of version definition table
Number of version definitions
Address of table with needed versions
Number of needed versions
Address of the table provided by the .gnu.version section.
An LSB-conforming implementation shall support the following base libraries which provide interfaces for accessing the operating system, processor and other hardware in the system.
libc
libm
libgcc_s
libdl
libcrypt
libpam
The Program Interpreter is specified in the appropriate architecture-specific LSB specification.
Table 1-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:
| Large File Support |
| this specification |
| SUSv2 |
| ISO POSIX (2003) |
| SVID Issue 3 |
| SVID Issue 4 |
An LSB conforming implementation shall provide the generic functions for RPC specified in Table 1-2, with the full mandatory functionality as described in the referenced underlying specification.
Table 1-2. libc - RPC Function Interfaces
| authnone_create [1] | svc_getreqset [2] | svcudp_create [3] | xdr_int [2] | xdr_u_long [2] |
| clnt_create [1] | svc_register [3] | xdr_accepted_reply [2] | xdr_long [2] | xdr_u_short [2] |
| clnt_pcreateerror [1] | svc_run [3] | xdr_array [2] | xdr_opaque [2] | xdr_union [2] |
| clnt_perrno [1] | svc_sendreply [3] | xdr_bool [2] | xdr_opaque_auth [2] | xdr_vector [2] |
| clnt_perror [1] | svcerr_auth [2] | xdr_bytes [2] | xdr_pointer [2] | xdr_void [2] |
| clnt_spcreateerror [1] | svcerr_decode [2] | xdr_callhdr [2] | xdr_reference [2] | xdr_wrapstring [2] |
| clnt_sperrno [1] | svcerr_noproc [2] | xdr_callmsg [2] | xdr_rejected_reply [2] | xdrmem_create [2] |
| clnt_sperror [1] | svcerr_noprog [2] | xdr_char [2] | xdr_replymsg [2] | xdrrec_create [2] |
| key_decryptsession [2] | svcerr_progvers [2] | xdr_double [2] | xdr_short [2] | xdrrec_eof [2] |
| pmap_getport [3] | svcerr_systemerr [2] | xdr_enum [2] | xdr_string [2] | |
| pmap_set [3] | svcerr_weakauth [2] | xdr_float [2] | xdr_u_char [2] | |
| pmap_unset [3] | svctcp_create [3] | xdr_free [2] | xdr_u_int [3] |
Referenced Specification(s)
[1]. SVID Issue 4
[2]. SVID Issue 3
[3]. this specification
An LSB conforming implementation shall provide the generic functions for System Calls specified in Table 1-3, with the full mandatory functionality as described in the referenced underlying specification.
Table 1-3. libc - System Calls Function Interfaces
| __fxstat [1] | fchmod [2] | getwd [2] | read [2] | setrlimit [2] |
| __getpgid [1] | fchown [2] | initgroups [1] | readdir [2] | setrlimit64 [3] |
| __lxstat [1] | fcntl [1] | ioctl [1] | readdir_r [2] | setsid [2] |
| __xmknod [1] | fdatasync [2] | kill [1] | readlink [2] | setuid [2] |
| __xstat [1] | flock [1] | killpg [2] | readv [2] | sleep [2] |
| access [2] | fork [2] | lchown [2] | rename [2] | statvfs [2] |
| acct [1] | fstatvfs [2] | link [1] | rmdir [2] | stime [1] |
| alarm [2] | fsync [2] | lockf [2] | sbrk [4] | symlink [2] |
| brk [4] | ftime [2] | lseek [2] | sched_get_priority_max [2] | sync [2] |
| chdir [2] | ftruncate [2] | mkdir [2] | sched_get_priority_min [2] | sysconf [2] |
| chmod [2] | getcontext [2] | mkfifo [2] | sched_getparam [2] | time [2] |
| chown [2] | getegid [2] | mlock [2] | sched_getscheduler [2] | times [2] |
| chroot [4] | geteuid [2] | mlockall [2] | sched_rr_get_interval [2] | truncate [2] |
| clock [2] | getgid [2] | mmap [2] | sched_setparam [2] | ulimit [2] |
| close [2] | getgroups [2] | mprotect [2] | sched_setscheduler [2] | umask [2] |
| closedir [2] | getitimer [2] | msync [2] | sched_yield [2] | uname [2] |
| creat [2] | getloadavg [1] | munlock [2] | select [2] | unlink [1] |
| dup [2] | getpagesize [4] | munlockall [2] | setcontext [2] | utime [2] |
| dup2 [2] | getpgid [2] | munmap [2] | setegid [2] | utimes [2] |
| execl [2] | getpgrp [2] | nanosleep [2] | seteuid [2] | vfork [2] |
| execle [2] | getpid [2] | nice [2] | setgid [2] | wait [2] |
| execlp [2] | getppid [2] | open [2] | setitimer [2] | wait4 [1] |
| execv [2] | getpriority [2] | opendir [2] | setpgid [2] | waitpid [1] |
| execve [2] | getrlimit [2] | pathconf [2] | setpgrp [2] | write [2] |
| execvp [2] | getrusage [2] | pause [2] | setpriority [2] | writev [2] |
| exit [2] | getsid [2] | pipe [2] | setregid [2] | |
| fchdir [2] | getuid [2] | poll [2] | setreuid [2] |
Referenced Specification(s)
[1]. this specification
[2]. ISO POSIX (2003)
[3]. Large File Support
[4]. SUSv2
An LSB conforming implementation shall provide the generic functions for Standard I/O specified in Table 1-4, with the full mandatory functionality as described in the referenced underlying specification.
Table 1-4. libc - Standard I/O Function Interfaces
| _IO_feof [1] | fgetpos [2] | fsetpos [2] | putchar [2] | sscanf [1] |
| _IO_getc [1] | fgets [2] | ftell [2] | putchar_unlocked [2] | telldir [2] |
| _IO_putc [1] | fgetwc_unlocked [1] | ftello [2] | puts [2] | tempnam [2] |
| _IO_puts [1] | fileno [2] | fwrite [2] | putw [3] | ungetc [2] |
| asprintf [1] | flockfile [2] | getc [2] | remove [2] | vasprintf [1] |
| clearerr [2] | fopen [2] | getc_unlocked [2] | rewind [2] | vdprintf [1] |
| ctermid [2] | fprintf [2] | getchar [2] | rewinddir [2] | vfprintf [2] |
| fclose [2] | fputc [2] | getchar_unlocked [2] | scanf [1] | vprintf [2] |
| fdopen [2] | fputs [2] | getw [3] | seekdir [2] | vsnprintf [2] |
| feof [2] | fread [2] | pclose [2] | setbuf [2] | vsprintf [2] |
| ferror [2] | freopen [2] | popen [2] | setbuffer [1] | |
| fflush [2] | fscanf [1] | printf [2] | setvbuf [2] | |
| fflush_unlocked [1] | fseek [2] | putc [2] | snprintf [2] | |
| fgetc [2] | fseeko [2] | putc_unlocked [2] | sprintf [2] |
Referenced Specification(s)
[1]. this specification
[2]. ISO POSIX (2003)
[3]. SUSv2
An LSB conforming implementation shall provide the generic data interfaces for Standard I/O specified in Table 1-5, with the full mandatory functionality as described in the referenced underlying specification.
Referenced Specification(s)
[1]. ISO POSIX (2003)
An LSB conforming implementation shall provide the generic functions for Signal Handling specified in Table 1-6, with the full mandatory functionality as described in the referenced underlying specification.
Table 1-6. libc - Signal Handling Function Interfaces
| __libc_current_sigrtmax [1] | sigaction [2] | sighold [2] | sigorset [1] | sigset [2] |
| __libc_current_sigrtmin [1] | sigaddset [2] | sigignore [2] | sigpause [2] | sigsuspend [2] |
| __sigsetjmp [1] | sigaltstack [2] | siginterrupt [2] | sigpending [2] | sigtimedwait [2] |
| __sysv_signal [1] | sigandset [1] | sigisemptyset [1] | sigprocmask [2] | sigwait [2] |
| bsd_signal [2] | sigdelset [2] | sigismember [2] | sigqueue [2] | sigwaitinfo [2] |
| psignal [1] | sigemptyset [2] | siglongjmp [2] | sigrelse [2] | |
| raise [2] | sigfillset [2] | signal [2] | sigreturn [1] |
Referenced Specification(s)
[1]. this specification
[2]. ISO POSIX (2003)
An LSB conforming implementation shall provide the generic data interfaces for Signal Handling specified in Table 1-7, with the full mandatory functionality as described in the referenced underlying specification.
Referenced Specification(s)
[1]. this specification
An LSB conforming implementation shall provide the generic functions for Localization Functions specified in Table 1