EXECUTABLE AND LINKABLE FORMAT (ELF)
时间：2007-02-26 来源：loughsky
Notes on the Flat-Text Transcription
The content of this transcription differs from the content of the
original document in the following ways.
1. Page breaks and pagination have been omitted.
2. As a result of the above, the page numbers have been left out of
the table of contents, and the index has been omitted entirely.
(Unlike a Postscript document, a text file can be searched.)
3. The contents of the title page and the footer text has been placed
at the beginning.
4. The lines and boxes in the original figures and tables have been
adapted.
5. Differing fonts have, of necessity, been elided. For the most part,
the context is sufficient to understand the meaning. In a few
places, however, the original document used italics to implicitly
indicate that the text stood for a variable string. In these cases,
I have used <angle brackets> around the text to indicate this.
There are no occurrences of angle brackets in the original.
6. The original contains three errors which are not immediately
obvious as such upon a casual reading, but which can be
unambiguously identified as such and the proper contents
determined. I have taken the liberty to correct these errors. Their
locations are marked in the text by a {*}. Any other (seeming)
errors I have let stand.
Any other differences between the contents of this file and the
original are my responsibility. Direct notices of such errors to
[email protected].
Brian Raiter
[Last edited Fri Jul 23 1999]
________________________________________________________________
EXECUTABLE AND LINKABLE FORMAT (ELF)
Portable Formats Specification, Version 1.1
Tool Interface Standards (TIS)
________________________________________________________________
=========================== Contents ===========================
PREFACE
1. OBJECT FILES
Introduction
ELF Header
Sections
String Table
Symbol Table
Relocation
2. PROGRAM LOADING AND DYNAMIC LINKING
Introduction
Program Header
Program Loading
Dynamic Linking
3. C LIBRARY
C Library
________________________________________________________________
PREFACE
________________________________________________________________
ELF: Executable and Linking Format
The Executable and Linking Format was originally developed and
published by UNIX System Laboratories (USL) as part of the Application
Binary Interface (ABI). The Tool Interface Standards committee (TIS)
has selected the evolving ELF standard as a portable object file
format that works on 32-bit Intel Architecture environments for a
variety of operating systems.
The ELF standard is intended to streamline software development by
providing developers with a set of binary interface definitions that
extend across multiple operating environments. This should reduce the
number of different interface implementations, thereby reducing the
need for recoding and recompiling code.
About This Document
This document is intended for developers who are creating object or
executable files on various 32-bit environment operating systems. It
is divided into the following three parts:
* Part 1, ``Object Files'' describes the ELF object file format for
the three main types of object files.
* Part 2, ``Program Loading and Dynamic Linking'' describes the object
file information and system actions that create running programs.
* Part 3, ``C Library'' lists the symbols contained in libsys, the
standard ANSI C and libc routines, and the global data symbols
required by the libc routines.
NOTE: References to X86 architecture have been changed to Intel
Architecture.
________________________________________________________________
1. OBJECT FILES
________________________________________________________________
========================= Introduction =========================
Part 1 describes the iABI object file format, called ELF (Executable
and Linking Format). There are three main types of object files.
* A relocatable file holds code and data suitable for linking with
other object files to create an executable or a shared object file.
* An executable file holds a program suitable for execution; the file
specifies how exec(BA_OS) creates a program's process image.
* A shared object file holds code and data suitable for linking in two
contexts. First, the link editor [see ld(SD_CMD)] may process it
with other relocatable and shared object files to create another
object file. Second, the dynamic linker combines it with an
executable file and other shared objects to create a process image.
Created by the assembler and link editor, object files are binary
representations of programs intended to execute directly on a
processor. Programs that require other abstract machines, such as
shell scripts, are excluded.
After the introductory material, Part 1 focuses on the file format and
how it pertains to building programs. Part 2 also describes parts of
the object file, concentrating on the information necessary to execute
a program.
File Format
Object files participate in program linking (building a program) and
program execution (running a program). For convenience and efficiency,
the object file format provides parallel views of a file's contents,
reflecting the differing needs of these activities. Figure 1-1 shows
an object file's organization.
+ Figure 1-1: Object File Format
Linking View Execution View
============ ==============
ELF header ELF header
Program header table (optional) Program header table
Section 1 Segment 1
... Segment 2
Section n ...
Section header table Section header table (optional)
An ELF header resides at the beginning and holds a ``road map''
describing the file's organization. Sections hold the bulk of object
file information for the linking view: instructions, data, symbol
table, relocation information, and so on. Descriptions of special
sections appear later in Part 1. Part 2 discusses segments and the
program execution view of the file.
A program header table, if present, tells the system how to create a
process image. Files used to build a process image (execute a program)
must have a program header table; relocatable files do not need one. A
section header table contains information describing the file's
sections. Every section has an entry in the table; each entry gives
information such as the section name, the section size, etc. Files
used during linking must have a section header table; other object
files may or may not have one.
NOTE: Although the figure shows the program header table immediately
after the ELF header, and the section header table following the
sections, actual files may differ. Moreover, sections and segments
have no specified order. Only the ELF header has a fixed position in
the file.
Data Representation
As described here, the object file format supports various processors
with 8-bit bytes and 32-bit architectures. Nevertheless, it is
intended to be extensible to larger (or smaller) architectures.
Object files therefore represent some control data with a
machine-independent format, making it possible to identify object
files and interpret their contents in a common way. Remaining data in
an object file use the encoding of the target processor, regardless of
the machine on which the file was created.
+ Figure 1-2: 32-Bit Data Types
Name Size Alignment Purpose
==== ==== ========= =======
Elf32_Addr 4 4 Unsigned program address
Elf32_Half 2 2 Unsigned medium integer
Elf32_Off 4 4 Unsigned file offset
Elf32_Sword 4 4 Signed large integer
Elf32_Word 4 4 Unsigned large integer
unsigned char 1 1 Unsigned small integer
All data structures that the object file format defines follow the
``natural'' size and alignment guidelines for the relevant class. If
necessary, data structures contain explicit padding to ensure 4-byte
alignment for 4-byte objects, to force structure sizes to a multiple
of 4, etc. Data also have suitable alignment from the beginning of the
file. Thus, for example, a structure containing an Elf32_Addr member
will be aligned on a 4-byte boundary within the file.
For portability reasons, ELF uses no bit-fields.
========================== ELF Header ==========================
Some object file control structures can grow, because the ELF header
contains their actual sizes. If the object file format changes, a
program may encounter control structures that are larger or smaller
than expected. Programs might therefore ignore``extra'' information.
The treatment of ``missing'' information depends on context and will
be specified when and if extensions are defined.
+ Figure 1-3: ELF Header
#define EI_NIDENT 16
typedef struct {
unsigned char e_ident[EI_NIDENT];
Elf32_Half e_type;
Elf32_Half e_machine;
Elf32_Word e_version;
Elf32_Addr e_entry;
Elf32_Off e_phoff;
Elf32_Off
The content of this transcription differs from the content of the
original document in the following ways.
1. Page breaks and pagination have been omitted.
2. As a result of the above, the page numbers have been left out of
the table of contents, and the index has been omitted entirely.
(Unlike a Postscript document, a text file can be searched.)
3. The contents of the title page and the footer text has been placed
at the beginning.
4. The lines and boxes in the original figures and tables have been
adapted.
5. Differing fonts have, of necessity, been elided. For the most part,
the context is sufficient to understand the meaning. In a few
places, however, the original document used italics to implicitly
indicate that the text stood for a variable string. In these cases,
I have used <angle brackets> around the text to indicate this.
There are no occurrences of angle brackets in the original.
6. The original contains three errors which are not immediately
obvious as such upon a casual reading, but which can be
unambiguously identified as such and the proper contents
determined. I have taken the liberty to correct these errors. Their
locations are marked in the text by a {*}. Any other (seeming)
errors I have let stand.
Any other differences between the contents of this file and the
original are my responsibility. Direct notices of such errors to
[email protected].
Brian Raiter
[Last edited Fri Jul 23 1999]
________________________________________________________________
EXECUTABLE AND LINKABLE FORMAT (ELF)
Portable Formats Specification, Version 1.1
Tool Interface Standards (TIS)
________________________________________________________________
=========================== Contents ===========================
PREFACE
1. OBJECT FILES
Introduction
ELF Header
Sections
String Table
Symbol Table
Relocation
2. PROGRAM LOADING AND DYNAMIC LINKING
Introduction
Program Header
Program Loading
Dynamic Linking
3. C LIBRARY
C Library
________________________________________________________________
PREFACE
________________________________________________________________
ELF: Executable and Linking Format
The Executable and Linking Format was originally developed and
published by UNIX System Laboratories (USL) as part of the Application
Binary Interface (ABI). The Tool Interface Standards committee (TIS)
has selected the evolving ELF standard as a portable object file
format that works on 32-bit Intel Architecture environments for a
variety of operating systems.
The ELF standard is intended to streamline software development by
providing developers with a set of binary interface definitions that
extend across multiple operating environments. This should reduce the
number of different interface implementations, thereby reducing the
need for recoding and recompiling code.
About This Document
This document is intended for developers who are creating object or
executable files on various 32-bit environment operating systems. It
is divided into the following three parts:
* Part 1, ``Object Files'' describes the ELF object file format for
the three main types of object files.
* Part 2, ``Program Loading and Dynamic Linking'' describes the object
file information and system actions that create running programs.
* Part 3, ``C Library'' lists the symbols contained in libsys, the
standard ANSI C and libc routines, and the global data symbols
required by the libc routines.
NOTE: References to X86 architecture have been changed to Intel
Architecture.
________________________________________________________________
1. OBJECT FILES
________________________________________________________________
========================= Introduction =========================
Part 1 describes the iABI object file format, called ELF (Executable
and Linking Format). There are three main types of object files.
* A relocatable file holds code and data suitable for linking with
other object files to create an executable or a shared object file.
* An executable file holds a program suitable for execution; the file
specifies how exec(BA_OS) creates a program's process image.
* A shared object file holds code and data suitable for linking in two
contexts. First, the link editor [see ld(SD_CMD)] may process it
with other relocatable and shared object files to create another
object file. Second, the dynamic linker combines it with an
executable file and other shared objects to create a process image.
Created by the assembler and link editor, object files are binary
representations of programs intended to execute directly on a
processor. Programs that require other abstract machines, such as
shell scripts, are excluded.
After the introductory material, Part 1 focuses on the file format and
how it pertains to building programs. Part 2 also describes parts of
the object file, concentrating on the information necessary to execute
a program.
File Format
Object files participate in program linking (building a program) and
program execution (running a program). For convenience and efficiency,
the object file format provides parallel views of a file's contents,
reflecting the differing needs of these activities. Figure 1-1 shows
an object file's organization.
+ Figure 1-1: Object File Format
Linking View Execution View
============ ==============
ELF header ELF header
Program header table (optional) Program header table
Section 1 Segment 1
... Segment 2
Section n ...
Section header table Section header table (optional)
An ELF header resides at the beginning and holds a ``road map''
describing the file's organization. Sections hold the bulk of object
file information for the linking view: instructions, data, symbol
table, relocation information, and so on. Descriptions of special
sections appear later in Part 1. Part 2 discusses segments and the
program execution view of the file.
A program header table, if present, tells the system how to create a
process image. Files used to build a process image (execute a program)
must have a program header table; relocatable files do not need one. A
section header table contains information describing the file's
sections. Every section has an entry in the table; each entry gives
information such as the section name, the section size, etc. Files
used during linking must have a section header table; other object
files may or may not have one.
NOTE: Although the figure shows the program header table immediately
after the ELF header, and the section header table following the
sections, actual files may differ. Moreover, sections and segments
have no specified order. Only the ELF header has a fixed position in
the file.
Data Representation
As described here, the object file format supports various processors
with 8-bit bytes and 32-bit architectures. Nevertheless, it is
intended to be extensible to larger (or smaller) architectures.
Object files therefore represent some control data with a
machine-independent format, making it possible to identify object
files and interpret their contents in a common way. Remaining data in
an object file use the encoding of the target processor, regardless of
the machine on which the file was created.
+ Figure 1-2: 32-Bit Data Types
Name Size Alignment Purpose
==== ==== ========= =======
Elf32_Addr 4 4 Unsigned program address
Elf32_Half 2 2 Unsigned medium integer
Elf32_Off 4 4 Unsigned file offset
Elf32_Sword 4 4 Signed large integer
Elf32_Word 4 4 Unsigned large integer
unsigned char 1 1 Unsigned small integer
All data structures that the object file format defines follow the
``natural'' size and alignment guidelines for the relevant class. If
necessary, data structures contain explicit padding to ensure 4-byte
alignment for 4-byte objects, to force structure sizes to a multiple
of 4, etc. Data also have suitable alignment from the beginning of the
file. Thus, for example, a structure containing an Elf32_Addr member
will be aligned on a 4-byte boundary within the file.
For portability reasons, ELF uses no bit-fields.
========================== ELF Header ==========================
Some object file control structures can grow, because the ELF header
contains their actual sizes. If the object file format changes, a
program may encounter control structures that are larger or smaller
than expected. Programs might therefore ignore``extra'' information.
The treatment of ``missing'' information depends on context and will
be specified when and if extensions are defined.
+ Figure 1-3: ELF Header
#define EI_NIDENT 16
typedef struct {
unsigned char e_ident[EI_NIDENT];
Elf32_Half e_type;
Elf32_Half e_machine;
Elf32_Word e_version;
Elf32_Addr e_entry;
Elf32_Off e_phoff;
Elf32_Off
相关阅读 更多 +
