Linux Standard Base Core Specification 3.2

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.


Table of Contents
Foreword
Introduction
I. Introductory Elements
1. Scope
1.1. General
1.2. Module Specific Scope
2. References
2.1. Normative References
2.2. Informative References/Bibliography
3. Requirements
3.1. Relevant Libraries
3.2. LSB Implementation Conformance
3.3. LSB Application Conformance
4. Definitions
5. Terminology
6. Documentation Conventions
7. Relationship To ISO/IEC 9945 POSIX
8. Relationship To Other Linux Foundation Specifications
II. Executable And Linking Format (ELF)
9. Introduction
10. Low Level System Information
10.1. Operating System Interface
10.2. Machine Interface
11. Object Format
11.1. Object Files
11.2. Sections
11.3. Special Sections
11.4. Symbol Mapping
11.5. DWARF Extensions
11.6. Exception Frames
11.7. Symbol Versioning
11.8. ABI note tag
12. Dynamic Linking
12.1. Program Loading and Dynamic Linking
12.2. Program Header
12.3. Dynamic Entries
III. Base Libraries
13. Base Libraries
13.1. Introduction
13.2. Program Interpreter
13.3. Interfaces for libc
13.4. Data Definitions for libc
13.5. Interface Definitions for libc
13.6. Interfaces for libm
13.7. Data Definitions for libm
13.8. Interface Definitions for libm
13.9. Interfaces for libpthread
13.10. Data Definitions for libpthread
13.11. Interface Definitions for libpthread
13.12. Interfaces for libgcc_s
13.13. Data Definitions for libgcc_s
13.14. Interfaces for libdl
13.15. Data Definitions for libdl
13.16. Interface Definitions for libdl
13.17. Interfaces for librt
13.18. Data Definitions for librt
13.19. Interfaces for libcrypt
13.20. Interfaces for libpam
13.21. Data Definitions for libpam
13.22. Interface Definitions for libpam
IV. Utility Libraries
14. Utility Libraries
14.1. Introduction
14.2. Interfaces for libz
14.3. Data Definitions for libz
14.4. Interface Definitions for libz
14.5. Interfaces for libncurses
14.6. Data Definitions for libncurses
14.7. Interfaces for libutil
14.8. Interface Definitions for libutil
V. Commands and Utilities
15. Commands and Utilities
15.1. Commands and Utilities
15.2. Command Behavior
VI. Execution Environment
16. File System Hierarchy
16.1. /dev: Device Files
16.2. /etc: Host-specific system configuration
16.3. User Accounting Databases
16.4. Path For System Administration Utilities
17. Additional Recommendations
17.1. Recommendations for applications on ownership and permissions
18. Additional Behaviors
18.1. Mandatory Optional Behaviors
19. Localization
19.1. Introduction
19.2. Regular Expressions
19.3. Pattern Matching Notation
VII. System Initialization
20. System Initialization
20.1. Cron Jobs
20.2. Init Script Actions
20.3. Comment Conventions for Init Scripts
20.4. Installation and Removal of Init Scripts
20.5. Run Levels
20.6. Facility Names
20.7. Script Names
20.8. Init Script Functions
VIII. Users & Groups
21. Users & Groups
21.1. User and Group Database
21.2. User & Group Names
21.3. User ID Ranges
21.4. Rationale
IX. Package Format and Installation
22. Software Installation
22.1. Introduction
22.2. Package File Format
22.3. Package Script Restrictions
22.4. Package Tools
22.5. Package Naming
22.6. Package Dependencies
22.7. Package Architecture Considerations
A. Alphabetical Listing of Interfaces
A.1. libc
A.2. libcrypt
A.3. libdl
A.4. libm
A.5. libncurses
A.6. libpam
A.7. libpthread
A.8. librt
A.9. libutil
A.10. libz
B. Future Directions (Informative)
B.1. Introduction
B.2. Commands And Utilities
lsbinstall -- installation tool for various types of data
C. GNU Free Documentation License (Informative)
C.1. PREAMBLE
C.2. APPLICABILITY AND DEFINITIONS
C.3. VERBATIM COPYING
C.4. COPYING IN QUANTITY
C.5. MODIFICATIONS
C.6. COMBINING DOCUMENTS
C.7. COLLECTIONS OF DOCUMENTS
C.8. AGGREGATION WITH INDEPENDENT WORKS
C.9. TRANSLATION
C.10. TERMINATION
C.11. FUTURE REVISIONS OF THIS LICENSE
C.12. How to use this License for your documents
List of Figures
11-1. Version Definition Entries
11-2. Version Definition Auxiliary Entries
11-3. Version Needed Entries
11-4. Version Needed Auxiliary Entries
12-1. Dynamic Structure
List of Tables
2-1. Normative References
2-2. Other References
3-1. Standard Library Names
3-2. Standard Library Names defined in the Architecture Specific Parts of ISO/IEC 23360
10-1. Scalar Types
11-1. ELF Section Types
11-2. Additional Section Types
11-3. ELF Special Sections
11-4. Additional Special Sections
11-5. DWARF Exception Header value format
11-6. DWARF Exception Header application
11-7. Additional DWARF Call Frame Instructions
11-8. Call Frame Information Format
11-9. Common Information Entry Format
11-10. Frame Description Entry Format
11-11. .eh_frame_hdr Section Format
12-1. Linux Segment Types
13-1. libc Definition
13-2. libc - RPC Function Interfaces
13-3. libc - System Calls Function Interfaces
13-4. libc - System Calls Deprecated Function Interfaces
13-5. libc - Standard I/O Function Interfaces
13-6. libc - Standard I/O Data Interfaces
13-7. libc - Signal Handling Function Interfaces
13-8. libc - Signal Handling Deprecated Function Interfaces
13-9. libc - Signal Handling Data Interfaces
13-10. libc - Localization Functions Function Interfaces
13-11. libc - Localization Functions Data Interfaces
13-12. libc - Posix Spawn Option Function Interfaces
13-13. libc - Posix Advisory Option Function Interfaces
13-14. libc - Socket Interface Function Interfaces
13-15. libc - Socket Interface Data Interfaces
13-16. libc - Wide Characters Function Interfaces
13-17. libc - String Functions Function Interfaces
13-18. libc - String Functions Deprecated Function Interfaces
13-19. libc - IPC Functions Function Interfaces
13-20. libc - Regular Expressions Function Interfaces
13-21. libc - Character Type Functions Function Interfaces
13-22. libc - Time Manipulation Function Interfaces
13-23. libc - Time Manipulation Data Interfaces
13-24. libc - Terminal Interface Functions Function Interfaces
13-25. libc - System Database Interface Function Interfaces
13-26. libc - System Database Interface Deprecated Function Interfaces
13-27. libc - Language Support Function Interfaces
13-28. libc - Large File Support Function Interfaces
13-29. libc - Large File Support Deprecated Function Interfaces
13-30. libc - Standard Library Function Interfaces
13-31. libc - Standard Library Deprecated Function Interfaces
13-32. libc - Standard Library Data Interfaces
13-33. libm Definition
13-34. libm - Math Function Interfaces
13-35. libm - Math Deprecated Function Interfaces
13-36. libm - Math Data Interfaces
13-37. libpthread Definition
13-38. libpthread - Realtime Threads Function Interfaces
13-39. libpthread - Advanced Realtime Threads Function Interfaces
13-40. libpthread - Posix Threads Function Interfaces
13-41. libpthread - Posix Threads Deprecated Function Interfaces
13-42. libpthread - Thread aware versions of libc interfaces Function Interfaces
13-43. libgcc_s Definition
13-44. libdl Definition
13-45. libdl - Dynamic Loader Function Interfaces
13-46. librt Definition
13-47. librt - Shared Memory Objects Function Interfaces
13-48. librt - Clock Function Interfaces
13-49. librt - Timers Function Interfaces
13-50. librt - Message Queues Function Interfaces
13-51. libcrypt Definition
13-52. libcrypt - Encryption Function Interfaces
13-53. libpam Definition
13-54. libpam - Pluggable Authentication API Function Interfaces
14-1. libz Definition
14-2. libz - Compression Library Function Interfaces
14-3. libncurses Definition
14-4. libncurses - Curses Function Interfaces
14-5. libncurses - Curses Data Interfaces
14-6. libutil Definition
14-7. libutil - Utility Functions Function Interfaces
15-1. Commands And Utilities
15-2. Built In Utilities
15-1. Escape Sequences
21-1. Required User & Group Names
21-2. Optional User & Group Names
22-1. RPM File Format
22-2. Signature Format
22-3. Index Type values
22-4. Header Private Tag Values
22-5. Signature Tag Values
22-6. Signature Digest Tag Values
22-7. Signature Signing Tag Values
22-8. Package Info Tag Values
22-9. Installation Tag Values
22-10. File Info Tag Values
22-11. File Flags
22-12. Package Dependency Tag Values
22-13. Index Type values
22-14. Package Dependency Attributes
22-15. Other Tag Values
22-16. CPIO File Format
A-1. libc Function Interfaces
A-2. libc Data Interfaces
A-3. libcrypt Function Interfaces
A-4. libdl Function Interfaces
A-5. libm Function Interfaces
A-6. libm Data Interfaces
A-7. libncurses Function Interfaces
A-8. libncurses Data Interfaces
A-9. libpam Function Interfaces
A-10. libpthread Function Interfaces
A-11. librt Function Interfaces
A-12. libutil Function Interfaces
A-13. libz Function Interfaces

Foreword

This is version 3.2 of the Linux Standard Base Core Specification. 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.


Introduction

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:

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.


Chapter 1. Scope

1.1. General

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.


1.2. Module Specific Scope

This is the Core module of the Linux Standard Base (LSB), ISO/IEC 23360 Part 1. This module provides the fundamental system interfaces, libraries, and runtime environment upon which all conforming applications and libraries depend.

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.


Chapter 2. References

2.1. Normative References

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

NameTitleURL
Filesystem Hierarchy StandardFilesystem Hierarchy Standard (FHS) 2.3http://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/
Itanium™ C++ ABIItanium™ C++ ABI (Revision 1.83)http://refspecs.linux-foundation.org/cxxabi-1.83.html
Large File SupportLarge File Supporthttp://www.UNIX-systems.org/version2/whatsnew/lfs20mar.html
SUSv2CAE 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 3American Telephone and Telegraph Company, System V Interface Definition, Issue 3; Morristown, NJ, UNIX Press, 1989. (ISBN 0201566524)
SVID Issue 4System V Interface Definition, Fourth Edition
System V ABISystem V Application Binary Interface, Edition 4.1http://www.caldera.com/developers/devspecs/gabi41.pdf
System V ABI UpdateSystem V Application Binary Interface - DRAFT - 17 December 2003http://www.caldera.com/developers/gabi/2003-12-17/contents.html
X/Open CursesCAE Specification, May 1996, X/Open Curses, Issue 4, Version 2 (ISBN: 1-85912-171-3, C610), plus Corrigendum U018http://www.opengroup.org/publications/catalog/un.htm

2.2. Informative References/Bibliography

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

NameTitleURL
DWARF Debugging Information Format, Revision 2.0.0DWARF 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 PointIEC 60559:1989 Binary floating-point arithmetic for microprocessor systemshttp://www.ieee.org/
ISO/IEC TR14652ISO/IEC Technical Report 14652:2002 Specification method for cultural conventions
ITU-T V.42International Telecommunication Union Recommendation V.42 (2002): Error-correcting procedures for DCEs using asynchronous-to-synchronous conversionITUVhttp://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-V.42
Li18nux Globalization SpecificationLI18NUX 2000 Globalization Specification, Version 1.0 with Amendment 4http://www.openi18n.org/docs/html/LI18NUX-2000-amd4.htm
Linux Allocated Device RegistryLINUX ALLOCATED DEVICEShttp://www.lanana.org/docs/device-list/devices.txt
PAMOpen 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 AlgorithmIETF RFC 1321: The MD5 Message-Digest Algorithmhttp://www.ietf.org/rfc/rfc1321.txt
RFC 1831/1832 RPC & XDRIETF RFC 1831 & 1832http://www.ietf.org/
RFC 1833: Binding Protocols for ONC RPC Version 2IETF RFC 1833: Binding Protocols for ONC RPC Version 2http://www.ietf.org/rfc/rfc1833.txt
RFC 1950: ZLIB Compressed Data Format SpecicationIETF RFC 1950: ZLIB Compressed Data Format Specificationhttp://www.ietf.org/rfc/rfc1950.txt
RFC 1951: DEFLATE Compressed Data Format SpecificationIETF RFC 1951: DEFLATE Compressed Data Format Specification version 1.3http://www.ietf.org/rfc/rfc1951.txt
RFC 1952: GZIP File Format SpecificationIETF RFC 1952: GZIP file format specification version 4.3http://www.ietf.org/rfc/rfc1952.txt
RFC 2440: OpenPGP Message FormatIETF RFC 2440: OpenPGP Message Formathttp://www.ietf.org/rfc/rfc2440.txt
RFC 2821:Simple Mail Transfer ProtocolIETF RFC 2821: Simple Mail Transfer Protocolhttp://www.ietf.org/rfc/rfc2821.txt
RFC 2822:Internet Message FormatIETF RFC 2822: Internet Message Formathttp://www.ietf.org/rfc/rfc2822.txt
RFC 791:Internet ProtocolIETF RFC 791: Internet Protocol Specificationhttp://www.ietf.org/rfc/rfc791.txt
RPM Package FormatRPM Package Format V3.0http://www.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html
SUSv2 Commands and UtilitiesThe 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 Manualzlib 1.2 Manualhttp://www.gzip.org/zlib/

Chapter 3. Requirements

3.1. Relevant Libraries

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 relevant architecture specific part of ISO/IEC 23360.

Table 3-1. Standard Library Names

LibraryRuntime Name
libdllibdl.so.2
libcryptlibcrypt.so.1
libzlibz.so.1
libncurseslibncurses.so.5
libutillibutil.so.1
libpthreadlibpthread.so.0
librtlibrt.so.1
libpamlibpam.so.0
libgcc_slibgcc_s.so.1

Table 3-2. Standard Library Names defined in the Architecture Specific Parts of ISO/IEC 23360

LibraryRuntime Name
libmSee archLSB
libcSee archLSB
proginterpSee archLSB

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


3.2. LSB Implementation Conformance

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.


3.3. LSB Application Conformance

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.

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


Chapter 4. Definitions

For the purposes of this document, the following definitions, as specified in the ISO/IEC Directives, Part 2, 2001, 4th Edition, apply:

can 

be able to; there is a possibility of; it is possible to

cannot 

be unable to; there is no possibilty of; it is not possible to

may 

is permitted; is allowed; is permissible

need not 

it is not required that; no...is required

shall 

is to; is required to; it is required that; has to; only...is permitted; it is necessary

shall not 

is not allowed [permitted] [acceptable] [permissible]; is required to be not; is required that...be not; is not to be

should 

it is recommended that; ought to

should not 

it is not recommended that; ought not to


Chapter 5. Terminology

For the purposes of this document, the following terms apply:

archLSB

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.

Binary Standard

The total set of interfaces that are available to be used in the compiled binary code of a conforming application.

gLSB

The common part of the LSB Specification that describes those parts of the interface that remain constant across all hardware implementations of the LSB.

implementation-defined

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

Shell Script

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

Source Standard

The set of interfaces that are available to be used in the source code of a conforming application.

undefined

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

unspecified

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

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).


Chapter 6. Documentation Conventions

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,

forkpty(GLIBC_2.0) [SUSv3]

refers to the interface named forkpty() with symbol version GLIBC_2.0 that is defined in the SUSv3 reference.

Note: Symbol versions are defined in the architecture specific parts of ISO/IEC 23360 only.


Chapter 7. Relationship To ISO/IEC 9945 POSIX

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 Linux Foundation to converge the LSB Core Specification 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.


Chapter 8. Relationship To Other Linux Foundation Specifications

The LSB is the base for several other specification projects under the umbrella of the Linux Foundation (LF). This specification is the foundation, and other specifications build on the interfaces defined here. However, beyond those specifications listed as Normative References, this specification has no dependencies on other LF projects.


Chapter 9. Introduction

Executable and Linking Format (ELF) defines the object format for compiled applications. This specification supplements the information found in System V ABI Update and is intended to document additions made since the publication of that document.


Chapter 10. Low Level System Information

10.1. Operating System Interface

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.


10.2. Machine Interface

10.2.1. Data Representation

LSB-conforming applications shall use the data representation as defined in the Arcitecture specific ELF documents.


10.2.1.1. Fundamental Types

In addition to the fundamental types specified in the relevant architecture specific part of ISO/IEC 23360, a 1 byte data type is defined here.

Table 10-1. Scalar Types

TypeCC++sizeofAlignment (bytes)Architecture Representation
Integral_Boolbool11byte


Chapter 11. Object Format

11.1. Object Files

LSB-conforming implementations shall support the object file Executable and Linking Format (ELF), which is defined by the following documents:

Conforming implementations may also support other unspecified object file formats.


11.2. Sections

11.2.1. Introduction

As described in System V ABI, an ELF object file contains a number of sections.


11.2.2. Sections Types

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 11-1, drawn from the System V ABI, or one of the additional values specified in Table 11-2.

A section header's sh_type member specifies the sections's semantics.


11.2.2.1. ELF Section Types

The following section types are defined in the System V ABI and the System V ABI Update.

Table 11-1. ELF Section Types

NameValueDescription
SHT_DYNAMIC0x6The 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 of System V ABI Update for details.
SHT_DYNSYM0xbThis 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_ARRAY0xfThis section contains an array of pointers to termination functions, as described in `Initialization and Termination Functions' in Chapter 5 of System V ABI Update. Each pointer in the array is taken as a parameterless procedure with a void return.
SHT_HASH0x5The 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 Chapter 5 of System V ABI Update for details.
SHT_INIT_ARRAY0xeThis section contains an array of pointers to initialization functions, as described in `Initialization and Termination Functions' in Chapter 5 of System V ABI Update. Each pointer in the array is taken as a parameterless procedure with a void return.
SHT_NOBITS0x8A 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_NOTE0x7The section holds information that marks the file in some way. See `Note Section' in Chapter 5 of System V ABI Update for details.
SHT_NULL0x0This 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_ARRAY0x10This 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 of System V ABI Update. Each pointer in the array is taken as a parameterless proceure with a void return.
SHT_PROGBITS0x1The section holds information defined by the program, whose format and meaning are determined solely by the program.
SHT_REL0x9The 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' in Chapter 4 of System V ABI Update for details.
SHT_RELA0x4The 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. See `Relocation' in Chapter 4 of System V ABI Update for details.
SHT_STRTAB0x3The section holds a string table. An object file may have multiple string table sections. See `String Table' in Chapter 4 of System V ABI Update for details.
SHT_SYMTAB0x2This 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.


11.2.2.2. Additional Section Types

The following additional section types are defined here.

Table 11-2. Additional Section Types

NameValueDescription
SHT_GNU_verdef0x6ffffffdThis section contains the symbol versions that are provided.
SHT_GNU_verneed0x6ffffffeThis section contains the symbol versions that are required.
SHT_GNU_versym0x6fffffffThis section contains the Symbol Version Table.


11.3. Special Sections

11.3.1. Special Sections

Various sections hold program and control information. Sections in the lists below are used by the system and have the indicated types and attributes.


11.3.1.1. ELF Special Sections

The following sections are defined in the System V ABI and the System V ABI Update.

Table 11-3. ELF Special Sections

NameTypeAttributes
.bssSHT_NOBITSSHF_ALLOC+SHF_WRITE
.commentSHT_PROGBITS0
.dataSHT_PROGBITSSHF_ALLOC+SHF_WRITE
.data1SHT_PROGBITSSHF_ALLOC+SHF_WRITE
.debugSHT_PROGBITS0
.dynamicSHT_DYNAMICSHF_ALLOC+SHF_WRITE
.dynstrSHT_STRTABSHF_ALLOC
.dynsymSHT_DYNSYMSHF_ALLOC
.finiSHT_PROGBITSSHF_ALLOC+SHF_EXECINSTR
.fini_arraySHT_FINI_ARRAYSHF_ALLOC+SHF_WRITE
.hashSHT_HASHSHF_ALLOC
.initSHT_PROGBITSSHF_ALLOC+SHF_EXECINSTR
.init_arraySHT_INIT_ARRAY SHF_ALLOC+SHF_WRITE
.interpSHT_PROGBITSSHF_ALLOC
.lineSHT_PROGBITS0
.noteSHT_NOTE0
.preinit_arraySHT_PREINIT_ARRAYSHF_ALLOC+SHF_WRITE
.rodataSHT_PROGBITSSHF_ALLOC+SHF_MERGE+SHF_STRINGS
.rodata1SHT_PROGBITSSHF_ALLOC+SHF_MERGE+SHF_STRINGS
.shstrtabSHT_STRTAB0
.strtabSHT_STRTABSHF_ALLOC
.symtabSHT_SYMTABSHF_ALLOC
.tbssSHT_NOBITSSHF_ALLOC+SHF_WRITE+SHF_TLS
.tdataSHT_PROGBITSSHF_ALLOC+SHF_WRITE+SHF_TLS
.textSHT_PROGBITSSHF_ALLOC+SHF_EXECINSTR

.bss 

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.

.comment 

This section holds version control information.

.data 

This section holds initialized data that contribute to the program's memory image.

.data1 

This section holds initialized data that contribute to the program's memory image.

.debug 

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.

.dynamic 

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 of System V ABI Update for more information.

.dynstr 

This section holds strings needed for dynamic linking, most commonly the strings that represent the names associated with symbol table entries. See Chapter 5 of System V ABI Update for more information.

.dynsym 

This section holds the dynamic linking symbol table, as described in `Symbol Table' of System V ABI Update.

.fini 

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.

.fini_array 

This section holds an array of function pointers that contributes to a single termination array for the executable or shared object containing the section.

.hash 

This section holds a symbol hash table. See `Hash Table' in Chapter 5 of System V ABI Update for more information.

.init 

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).

.init_array 

This section holds an array of function pointers that contributes to a single initialization array for the executable or shared object containing the section.

.interp 

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 of System V ABI Update for more information.

.line 

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.

.note 

This section holds information in the format that `Note Section' in Chapter 5 of System V ABI Update describes.

.preinit_array 

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.

.rodata 

This section holds read-only data that typically contribute to a non-writable segment in the process image. See `Program Header' in Chapter 5 of System V ABI Update for more information.

.rodata1 

This section holds read-only data that typically contribute to a non-writable segment in the process image. See `Program Header' in Chapter 5 of System V ABI Update for more information.

.shstrtab 

This section holds section names.

.strtab 

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; otherwise, that bit will be off.

.symtab 

This section holds a symbol table, as `Symbol Table' in Chapter 4 of System V ABI Update 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.

.tbss 

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.

.tdata 

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.

.text 

This section holds the `text', or executable instructions, of a program.


11.3.1.2. Additional Special Sections

Object files in an LSB conforming application may also contain one or more of the additional special sections described below.

Table 11-4. Additional Special Sections

NameTypeAttributes
.ctorsSHT_PROGBITSSHF_ALLOC+SHF_WRITE
.data.rel.roSHT_PROGBITSSHF_ALLOC+SHF_WRITE
.dtorsSHT_PROGBITSSHF_ALLOC+SHF_WRITE
.eh_frameSHT_PROGBITSSHF_ALLOC
.eh_frame_hdrSHT_PROGBITSSHF_ALLOC
.gcc_except_tableSHT_PROGBITSSHF_ALLOC
.gnu.versionSHT_GNU_versymSHF_ALLOC
.gnu.version_dSHT_GNU_verdefSHF_ALLOC
.gnu.version_rSHT_GNU_verneedSHF_ALLOC
.got.pltSHT_PROGBITSSHF_ALLOC+SHF_WRITE
.jcrSHT_PROGBITSSHF_ALLOC+SHF_WRITE
.note.ABI-tagSHT_NOTESHF_ALLOC
.stabSHT_PROGBITS0
.stabstrSHT_STRTAB0

.ctors 

This section contains a list of global constructor function pointers.

.data.rel.ro 

This section holds initialized data that contribute to the program's memory image. This section may be made read-only after relocations have been applied.

.dtors 

This section contains a list of global destructor function pointers.

.eh_frame 

This section contains information necessary for frame unwinding during exception handling. See Section 11.6.1.

.eh_frame_hdr 

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. See Section 11.6.2.

.gcc_except_table 

This section holds Language Specific Data.

.gnu.version 

This section contains the Symbol Version Table. See Section 11.7.2.

.gnu.version_d 

This section contains the Version Definitions. See Section 11.7.3.

.gnu.version_r 

This section contains the Version Requirements. See Section 11.7.4.

.got.plt 

This section holds the read-only portion of the GLobal Offset Table. This section may be made read-only after relocations have been applied.

.jcr 

This section contains information necessary for registering compiled Java classes. The contents are compiler-specific and used by compiler initialization functions.

.note.ABI-tag 

Specify ABI details. See Section 11.8.

.stab 

This section contains debugging information. The contents are not specified as part of the LSB.

.stabstr 

This section contains strings associated with the debugging infomation contained in the .stab section.


11.4. Symbol Mapping

11.4.1. Introduction

Symbols in a source program are translated by the compilation system into symbols that exist in the object file.


11.4.1.1. C Language

External C symbols shall be unchanged in an object file's symbol table.


11.5. DWARF Extensions

The LSB does not specify debugging information, however, some additional sections contain information which is encoded using the the encoding as specified by DWARF Debugging Information Format, Revision 2.0.0 with extensions defined here.

Note: The extensions specified here also exist in DWARF Debugging Information Format, Revision 3.0.0 (Draft). It is expected that future versions of the LSB will reference the final version of that document, and that the definitions here will be taken from that document instead of being specified here.


11.5.1. DWARF Exception Header Encoding

The DWARF Exception Header Encoding is used to describe the type of data used in the .eh_frame and .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 11-5. DWARF Exception Header value format

NameValueMeaning
DW_EH_PE_absptr0x00The Value is a literal pointer whose size is determined by the architecture.
DW_EH_PE_uleb1280x01Unsigned value is encoded using the Little Endian Base 128 (LEB128) as defined by DWARF Debugging Information Format, Revision 2.0.0.
DW_EH_PE_udata20x02A 2 bytes unsigned value.
DW_EH_PE_udata40x03A 4 bytes unsigned value.
DW_EH_PE_udata80x04An 8 bytes unsigned value.
DW_EH_PE_sleb1280x09Signed value is encoded using the Little Endian Base 128 (LEB128) as defined by DWARF Debugging Information Format, Revision 2.0.0.
DW_EH_PE_sdata20x0AA 2 bytes signed value.
DW_EH_PE_sdata40x0BA 4 bytes signed value.
DW_EH_PE_sdata80x0CAn 8 bytes signed value.

Table 11-6. DWARF Exception Header application

NameValueMeaning
DW_EH_PE_pcrel0x10Value is relative to the current program counter.
DW_EH_PE_textrel0x20Value is relative to the beginning of the .text section.
DW_EH_PE_datarel0x30Value is relative to the beginning of the .got or .eh_frame_hdr section.
DW_EH_PE_funcrel0x40Value is relative to the beginning of the function.
DW_EH_PE_aligned0x50Value is aligned to an address unit sized boundary.

One special encoding, 0xff (DW_EH_PE_omit), shall be used to indicate that no value ispresent.


11.5.2. DWARF CFI Extensions

In addition to the Call Frame Instructions defined in section 6.4.2 of DWARF Debugging Information Format, Revision 2.0.0, the following additional Call Frame Instructions may also be used.

Table 11-7. Additional DWARF Call Frame Instructions

NameValueMeaning
DW_CFA_expression0x10The 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, Revision 2.0.0) cannot be used in such a DWARF expression.
DW_CFA_offset_extended_sf0x11The 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_sf0x12The 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_sf0x13The 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_size0x2eThe DW_CFA_GNU_args_size instruction takes an unsigned LEB128 operand representing an argument size. This instruction specifies the total of the size of the arguments which have been pushed onto the stack.
DW_CFA_GNU_negative_offset_extended0x2fThe 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.

11.6. Exception Frames

When using languages that support exceptions, such as C++, additional information must be provided to the runtime environment that describes the call frames that must be unwound during the processing of an exception. This information is contained in the special sections .eh_frame and .eh_framehdr.

Note: The format of the .eh_frame section is similar in format and purpose to the .debug_frame section which is specified in DWARF Debugging Information Format, Revision 3.0.0 (Draft). Readers are advised that there are some subtle difference, and care should be taken when comparing the two sections.


11.6.1. The .eh_frame section

The .eh_frame section shall contain 1 or more Call Frame Information (CFI) records. The number of records present shall be determined by size of the section as contained in the section header. Each CFI record contains a Common Information Entry (CIE) record followed by 1 or more Frame Description Entry (FDE) records. Both CIEs and FDEs shall be aligned to an addressing unit sized boundary.

Table 11-8. Call Frame Information Format

Common Information Entry Record
Frame Description Entry Record(s)

11.6.1.1. The Common Information Entry Format

Table 11-9. Common Information Entry Format

LengthRequired
Extended LengthOptional
CIE IDRequired
VersionRequired
Augmentation StringRequired
Code Alignment FactorRequired
Data Alignment FactorRequired
Return Address RegisterRequired
Augmentation Data LengthOptional
Augmentation DataOptional
Initial InstructionsRequired
Padding 

Length

A 4 byte unsigned value indicating the length in bytes of the CIE structure, not including the Length field itself. If Length contains the value 0xffffffff, then the length is contained in the Extended Length field. If Length contains the value 0, then this CIE shall be considered a terminator and processing shall end.

Extended Length

A 8 byte unsigned value indicating the length in bytes of the CIE structure, not including the Length and Extended Length fields.

CIE ID

A 4 byte unsigned value that is used to distinguish CIE records from FDE records. This value shall always be 0, which indicates this record is a CIE.

Version

A 1 byte value that identifies the version number of the frame information structure. This value shall be 1.

Augmentation String

This value is a NUL terminated string that identifies the augmentation to the CIE or to the FDEs associated with this CIE. A zero length string indicates that no augmentation data is present. The augmentation string is case sensitive and shall be interpreted as described below.

Code Alignment Factor

An unsigned LEB128 encoded value that is factored out of all advance location instructions that are associated with this CIE or its FDEs. This value shall be multiplied by the delta argument of an adavance location instruction to obtain the new location value.

Data Alignment Factor

A signed LEB128 encoded value that is factored out of all offset instructions that are associated with this CIE or its FDEs. This value shall be multiplied by the register offset argument of an offset instruction to obtain the new offset value.

Augmentation Length

An unsigned LEB128 encoded value indicating the length in bytes of the Augmentation Data. This field is only present if the Augmentation String contains the character 'z'.

Augmentation Data

A block of data whose contents are defined by the contents of the Augmentation String as described below. This field is only present if the Augmentation String contains the character 'z'. The size of this data is given by the Augentation Length.

Initial Instructions

Initial set of Call Frame Instructions. The number of instructions is determined by the remaining space in the CIE record.

Padding

Extra bytes to align the CIE structure to an addressing unit size boundary.


11.6.1.1.1. Augmentation String Format

The Agumentation String indicates the presence of some optional fields, and how those fields should be intepreted. This string is case sensitive. Each character in the augmentation string in the CIE can be interpreted as below:

'z' 

A 'z' may be present as the first character of the string. If present, the Augmentation Data field shall be present. The contents of the Augmentation Data shall be intepreted according to other characters in the Augmentation String.

'L' 

A 'L' may be present at any position after the first character of the string. This character may only be present if 'z' is the first character of the string. If present, it indicates the presence of one argument in the Augmentation Data of the CIE, and a corresponding argument in the Augmentation Data of the FDE. The argument in the Augmentation Data of the CIE is 1-byte and represents the pointer encoding used for the argument in the Augmentation Data of the FDE, which is the address of a language-specific data area (LSDA). The size of the LSDA pointer is specified by the pointer encoding used.

'P' 

A 'P' may be present at any position after the first character of the string. This character may only be present if 'z' is the first character of the string. If present, it indicates the presence of two arguments in the Augmentation Data of the CIE. The first argument is 1-byte and represents the pointer encoding used for the second argument, which is the address of a personality routine handler. The personality routine is used to handle language and vendor-specific tasks. The system unwind library interface accesses the language-specific exception handling semantics via the pointer to the personality routine. The personality routine does not have an ABI-specific name. The size of the personality routine pointer is specified by the pointer encoding used.

'R' 

A 'R' may be present at any position after the first character of the string. This character may only be present if 'z' is the first character of the string. If present, The Augmentation Data shall include a 1 byte argument that represents the pointer encoding for the address pointers used in the FDE.


11.6.1.2. The Frame Description Entry Format

Table 11-10. Frame Description Entry Format

LengthRequired
Extended LengthOptional
CIE PointerRequired
PC BeginRequired
PC RangeRequired
Augmentation Data LengthOptional
Augmentation DataOptional
Call Frame InstructionsRequired
Padding 

Length

A 4 byte unsigned value indicating the length in bytes of the CIE structure, not including the Length field itself. If Length contains the value 0xffffffff, then the length is contained the Extended Length field. If Length contains the value 0, then this CIE shall be considered a terminator and processing shall end.

Extended Length

A 8 byte unsigned value indicating the length in bytes of the CIE structure, not including the Length field itself.

CIE Pointer

A 4 byte unsigned value that when subtracted from the offset of the the CIE Pointer in the current FDE yields the offset of the start of the associated CIE. This value shall never be 0.

PC Begin

An encoded value that indicates the address of the initial location associated with this FDE. The encoding format is specified in the Augmentation Data.

PC Range

An absolute value that indicates the number of bytes of instructions associated with this FDE.

Augmentation Length

An unsigned LEB128 encoded value indicating the length in bytes of the Augmentation Data. This field is only present if the Augmentation String in the associated CIE contains the character 'z'.

Augmentation Data

A block of data whose contents are defined by the contents of the Augmentation String in the associated CIE as described above. This field is only present if the Augmentation String in the associated CIE contains the character 'z'. The size of this data is given by the Augentation Length.

Call Frame Instructions

A set of Call Frame Instructions.

Padding

Extra bytes to align the FDE structure to an addressing unit size boundary.


11.6.2. 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 Section 11.5.1.

Table 11-11. .eh_frame_hdr Section Format

EncodingField
unsigned byteversion
unsigned byteeh_frame_ptr_enc
unsigned bytefde_count_enc
unsigned bytetable_enc
encodedeh_frame_ptr
encodedfde_count
 binary search table

version 

Version of the .eh_frame_hdr format. This value shall be 1.

eh_frame_ptr_enc 

The encoding format of the eh_frame_ptr field.

fde_count_enc 

The encoding format of the fde_count field. A value of DW_EH_PE_omit indicates the binary search table is not present.

table_enc 

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.

eh_frame_ptr 

The encoded value of the pointer to the start of the .eh_frame section.

fde_count 

The encoded value of the count of entries in the binary search table.

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.


11.7. Symbol Versioning

11.7.1. Introduction

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.


11.7.2. Symbol Version Table

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.

0 

The symbol is local, not available outside the object.

1 

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.


11.7.3. Version Definitions

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 11-1, optionally followed by an array of Elfxx_Verdaux structures, as defined in Figure 11-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 11-1. Version Definition Entries

vd_version 

Version revision. This field shall be set to 1.

vd_flags 

Version information flag bitmask.

vd_ndx 

Version index numeric value referencing the SHT_GNU_versym section.

vd_cnt 

Number of associated verdaux array entries.

vd_hash 

Version name hash value (ELF hash function).

vd_aux 

Offset in bytes to a corresponding entry in an array of Elfxx_Verdaux structures as defined in Figure 11-2

vd_next 

Offset to the next verdef entry, in bytes.

typedef struct {
	Elfxx_Word    vda_name;
	Elfxx_Word    vda_next;
} Elfxx_Verdaux;

Figure 11-2. Version Definition Auxiliary Entries

vda_name 

Offset to the version or dependency name string in the section header, in bytes.

vda_next 

Offset to the next verdaux entry, in bytes.


11.7.4. Version Requirements

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 11-3, optionally followed by an array of Elfxx_Vernaux structures, as defined in Figure 11-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 11-3. Version Needed Entries

vn_version 

Version of structure. This value is currently set to 1, and will be reset if the versioning implementation is incompatibly altered.

vn_cnt 

Number of associated verneed array entries.

vn_file 

Offset to the file name string in the section header, in bytes.

vn_aux 

Offset to a corresponding entry in the vernaux array, in bytes.

vn_next 

Offset 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 11-4. Version Needed Auxiliary Entries

vna_hash 

Dependency name hash value (ELF hash function).

vna_flags 

Dependency information flag bitmask.

vna_other 

Object 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_name 

Offset to the dependency name string in the section header, in bytes.

vna_next 

Offset to the next vernaux entry, in bytes.


11.7.5. Startup Sequence

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.


11.7.6. Symbol Resolution

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 proc