64-bit ELF Object File Specification

Section 1: Introduction

This document specifies the format of MIPS object files for 64-bit code. We assume as a basis the documents [ABI32], [ABI32M], and [ABI64]. In addition, Silicon Graphics uses the DWARF debugging information format as specified in [DWARF]. Information in those documents should be considered valid unless contradicted here.

The remainder of this section summarizes our objectives, approach, and open issues. Section 2 corresponds to ABI Section 4, describing ELF-64 object files, and Section 3 corresponds to ABI Section 5, describing program loading and dynamic linking. Section 4 describes the 64-bit archive file format (from MIPS ABI Section 7), though it is not technically part of ELF.

1.1 Objectives

The objectives of this format definition fall in two categories. The first is simply to extend the base 32-bit ELF format, by increasing field sizes where appropriate, so that there will be no problems dealing with very large 64-bit programs. The second is to extend the kinds of information included in the object file to facilitate new features.

1. Remove 32-bit constraints on object file sizes.
2. Support checking and potential conversion of subprogram call interfaces.
3. Support efficient and reliable application of performance monitoring tools like pixie and object code optimization tools like cord.
4. Support efficient and reliable debugging facilities.

1.2 Approach

We start from the basis of the System V ABI and the MIPS symbol table format, extending them in the obvious ways to support very large objects. We will then add additional information (generally new sections) to support the extended objectives described above. We generally recognize three levels of support:

1. Some information is required for all ABI-compliant object files.
2. Some information is optional, but its absence will prevent use of system functionality, e.g. cache optimization reordering, etc.
3. Some information is entirely optional; its absence interferes only with functionality unrelated to program construction, e.g. debugging, performance measurement, etc.

To clarify the distinction between these levels, we have defined a new section header flag, SHF_MIPS_NOSTRIP, which is applied to sections in the first two levels. The intent is that a strip(1) tool or its equivalent should never remove these sections by default, and should warn the user if their removal is explicitly requested.

We have followed a number of principles and assumptions in this specification:

1. Sections expected to be used by runtime facilities, e.g. stack traceback, have the SHF_ALLOC attribute. Such sections also have symbols automatically generated by the linker which may be used to reference them in code. This allows simple virtual addressing in the process address space for any required access.
2. Sections are NOT given the SHF_WRITE attribute simply because rld may need to relocate their contents. We assume that rld can request write access and change it back if necessary, and prefer this approach for a more robust runtime environment.
3. We require that the executable code for a single executable or DSO will never be larger than 256MB, and that it will never be loaded across a 256MB boundary. This requirement allows various beneficial assumptions about valid addressing code within an executable/DSO, and also allows the use of single-word addresses (to be interpreted relative to the containing 4GB address range) for code in an object file.

1.3 Conventions

In all of the tables in this document, unshaded information is that derived directly from external documents (i.e. the generic ABI and the DWARF specification), lightly shaded information is derived directly from 32-bit MIPS specifications (ELF, header files), and heavily shaded information is new or substantially changed from these existing formats.

We use the usual wording to describe requirements, distinguishing between must (mandatory), should (recommended), and may (allowed).

1.4 Open Issues

Unresolved issues and missing information are marked in this document. The most significant ones at this time are:

1. Should there be a distinct EK_PBEGIN event in case a program unit does not begin with an entrypoint (Section 2.10)?
2. Should memory events be segregated to a distinct events section so that tools which use the default events and those which use the memory events aren't impacted by the other data (Section 2.10)?

Section 2: ELF-64 Object File Format

The ELF-64 object file format is based on the document [ABI64]. The relevant declarations are contained in the header file /usr/include/elf.h. (Note that /usr/include/sys/elf.h is logically part of /usr/include/elf.h, and is the actual location of most of these declarations.)

We call attention to the [ABI32] requirement that all data structures be naturally aligned in the file (see p. 4-3). This implies that all headers, sections, and other major components must be 8-byte aligned, with padding if necessary to accomplish this. Although 4-byte alignment is probably adequate currently for ELF-32, 8-byte alignment should also be used there to avoid future extension problems.

2.1 Infrastructure

ELF-64 is defined in terms of the types in Table 1:

There are places in ELF-64 files where fundamental data types must be encoded, for instance in subprogram interface descriptors. We generally use the constants in Table 2 to identify them, based on DWARF version 1 (but not identical).

2.2 ELF-64 Header

The header format is as defined in [ABI64]; it is reproduced here for reference purposes.

The structure of the e_ident field is given by Table 5.

2.3 ELF-64 Section Header

The section header format is as defined in [ABI64]; it is reproduced here for reference purposes.

2.5 Symbol Table

A symbol table section is unchanged from [ABI32] except for the types of some of its fields.

A symbol table section and its associated string table section must be present for any executable file with DSO dependencies, or for any DSO. It is permissible to remove from it symbols resolved within itself if they are not preemptible (protected) and not visible outside this object.

The high-order nibble of the st_info field specifies the symbol's binding (see Table 12), and the low-order nibble specifies its type (see Table 13).

2.9 Relocation

Any section may have an associated SHT_REL and/or SHT_RELA section, containing relocation operations for objects in the section.

Section 3: Program Linking and Loading

This section deals with aspects of the object file format specific to executable and DSO files (which we refer to collectively as program files), and with the processing required by the static linker ld(1) and the dynamic linker rld(1).

3.1 Linker (ld) Requirements

This section is obviously not an exhaustive list; it is intended to collect miscellaneous requirements which are not traditional and not obviously implied by the format description.

The intent of some of these requirements, along with the specification of most of the sections described above as having the SHF_ALLOC attribute by default, is to allow a program (or another process monitoring it at runtime, like a debugger) to access the information in its program file by simple references to its address space, rather than requiring that it explicitly read the program file.

3.1.1 Headers

The ELF header, program header table, and section header table will be allocated, i.e. they will be treated like sections with the SHF_ALLOC flag set. Although they are considered optional by [ABI32], section headers will be present in a MIPS ABI-compliant program file and may not be stripped.

3.2 Program Header

The program header of an executable/DSO file consists of an array of descriptors, one per loadable segment plus a few extras. The structure (from [ABI64]) is as follows:

3.3 Dynamic Linking

This section discusses the data structures and issues relevant to dynamic linking.

3.3.1 Dynamic Section

The .dynamic section, which must be identified by a PT_DYNAMIC segment descriptor for any executable or DSO with DSO dependencies, consists of a table of pairs with the following structure:

3.5 The Global Offset Table

The organization of the GOT generally follows that of [ABI32M]. It is essentially a table of addresses, 64 bits each. We summarize it here primarily for completeness.

The GOT itself is located by the DT_PLTGOT dynamic tag. It is logically two tables. The first (with DT_MIPS_LOCAL_GOTNO entries) consists of local GOT addresses, i.e. non-preemptible (protected) addresses defined within the executable/DSO. They are initialized to their quickstart values, and must be relocated if and only if the DSO is loaded at a different address than that given by its DT_MIPS_BASE_ADDRESS dynamic tag.

The second part of the GOT is the global GOT addresses, i.e. those which are undefined or preemptible. Each entry in this part has an associated symbol entry in the .dynsym section. Those symbols start at the symbol table index given by the DT_MIPS_GOTSYM dynamic tag, and are in the same order as the global GOT entries.

Section 4: Archive File Format

The archive file (i.e. ar(4) format) may be used to collect arbitrary files; we are concerned here with the specific case where those files are ELF object files. This format is based on the System V ABI [ABI32]; in particular, the magic string and member header format are unchanged.

Unlike the COFF archive format, we do not generate an archive hash table, since the IRIX 6.0 linker (ld) does not use it.

The linker (ld) will work more efficiently when component object files (not their file headers) are 8-byte aligned. Generating tools (especially the compilers) are encouraged to arrange this by padding them, i.e. by increasing the length of the component files to a multiple of 8 bytes.

4.1 Basic File Format

An object file archive consists of the following sequence of components. In general, each must start on a 2-byte boundary, and is padded with a newline if necessary to make it even length. Its ar_size in its header, however, does not include the padding byte.

• The archive magic string, ARMAG ("!<arch>\n"), SARMAG (8) bytes long.

The remaining components are all preceded with a member header as specified by [ELF32].

• An optional archive symbol table. This table is discussed further below.
• An optional archive string table. Such a component has ar_name="//" in its header, blank padded. The string table consists of a sequence of null-terminated names.
• Some number of "normal" member files. The ar_name field of such a component contains its filename, slash-terminated and blank-padded, if it fits. Otherwise it contains a slash followed by the decimal representation of the name's file offset in the archive string table.

4.2 Archive Symbol Table Components

We define below two symbol table component formats. These are the current 32-bit ABI format and an analogous 64-bit form for 64-bit ELF object files.

• 32-bit generic ABI symbol table (see [ABI32]). Such a component has ar_name="/" in its header, i.e. a null file name, blank padded. This symbol table consists of:
  • The number of symbols defined (a 32-bit count).
  • A sequence of 32-bit file offsets, one for each symbol, relative to the beginning of the archive file.
  • A sequence of null-terminated symbol names, one for each symbol.
• 64-bit generic ABI style symbol table. Such a component has ar_name="/SYM64/" in its header, blank padded. This symbol table consists of:
  • The number of symbols defined (a 64-bit count).
  • A sequence of 64-bit file offsets, one for each symbol, relative to the beginning of the archive file.
  • A sequence of null-terminated symbol names, one for each symbol.

Bibliography