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") describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific supplement ("LSB-arch" or "archLSB") 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.

1.2. Module Specific Scope

This is the Itanium architecture specific Core module of the Linux Standards Base (LSB). This module supplements the generic LSB Core module with those interfaces that differ between architectures.

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.

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.

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.

3.1. Relevant Libraries

The libraries listed in Table 3-1 shall be available on IA64 Linux Standard Base systems, with the specified runtime names. These names override or supplement the names specified in the generic LSB specification. The specified program interpreter, referred to as proginterp in this table, shall be used to load the shared libraries specified by DT_NEEDED entries at run time.

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 and its relevant architecture specific supplement.

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 supplement to this specification for a given target processor architecture describes 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 and its relevant architecture specific supplement.

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.

8.1. Machine Interface

    struct {
        char c;
    }
   

    struct {
        char  c;
        char  d;
        short s;
        int   i;
        long  l;
    }
   

    struct {
        char  c;
        long  l;
        int   i;
        short s;
    }
   

signed char
char
unsigned char
     

-2w-1 to 2w-1-1
0 to 2w-1
0 to 2w-1
     

signed short
short
unsigned short
     

-2w-1 to 2w-1-1
0 to 2w-1
0 to 2w-1
     

signed int
int
unsigned int
     

-2w-1 to 2w-1-1
0 to 2w-1
0 to 2w-1
     

signed long
long
unsigned long
     

-2w-1 to 2w-1-1
0 to 2w-1
0 to 2w-1
     

8.2. Function Calling Sequence

LSB-conforming applications shall use the procedure linkage and function calling sequence as defined in Chapter 8.4 of the Itanium ™ Software Conventions and Runtime Guide.

8.3. Operating System Interface

LSB-conforming applications shall use the Operating System Interfaces as defined in Chapter 3 of the Intel® Itanium ™ Processor-specific Application Binary Interface.

8.4. Process Initialization

LSB-conforming applications shall use the Process Startup as defined in Section 3.3.5 of the Intel® Itanium ™ Processor-specific Application Binary Interface.

typedef struct
{
  long int a_type;              /* Entry type */
  union
    {
      long int a_val;           /* Integer value */
      void *a_ptr;              /* Pointer value */
      void (*a_fcn) (void);     /* Function pointer value */
    } a_un;
} auxv_t;

8.5. Coding Examples

8.6. C Stack Frame

8.7. Debug Information

The LSB does not currently specify the format of Debug information.

9.1. Introduction

LSB-conforming implementations shall support an object file , called Executable and Linking Format (ELF) as defined by the System V ABI, Intel® Itanium ™ Processor-specific Application Binary Interface and as supplemented by the Linux Standard Base Specification and this document.

9.2. ELF Header

9.3. Sections

The Itanium™ architecture defines two processor-specific section types, as described in Intel® Itanium ™ Processor-specific Application Binary Interface, Chapter 4.

9.4. Symbol Table

If an executable file contains a reference to a function defined in one of its associated shared objects, the symbol table section for that file shall contain an entry for that symbol. The st_shndx member of that symbol table entry contains SHN_UNDEF. This signals to the dynamic linker that the symbol definition for that function is not contained in the executable file itself. If that symbol has been allocated a procedure linkage table entry in the executable file, and the st_value member for that symbol table entry is non-zero, the value shall contain the virtual address of the first instruction of that procedure linkage table entry. Otherwise, the st_value member contains zero. This procedure linkage table entry address is used by the dynamic linker in resolving references to the address of the function.

9.5. Relocation

10.1. Introduction

LSB-conforming implementations shall support the object file information and system actions that create running programs as specified in the System V ABI, Intel® Itanium ™ Processor-specific Application Binary Interface and as supplemented by the Linux Standard Base Specification and this document.

10.2. Program Header

The program header shall be as defined in the Intel® Itanium ™ Processor-specific Application Binary Interface, Chapter 5.

10.3. Program Loading

See Intel® Itanium ™ Processor-specific Application Binary Interface, Chapter 5.2.

10.4. Dynamic Linking

See Intel® Itanium ™ Processor-specific Application Binary Interface, Chapter 5.3.

11.1. Program Interpreter/Dynamic Linker

The Program Interpreter shall be /lib/ld-lsb-ia64.so.3.

11.2. Interfaces for libc

Table 11-1 defines the library name and shared object name for the libc library

The behavior of the interfaces in this library is specified by the following specifications: