ELF format detailed

The format of the arm executable file is an elf format file, which is described in detail below in the ELF format.

Preface
1. Object File
Introduction
Elf Head (elf header)
Sections
String table
Symbol tables (symbol table)
Relocation (relocation)
2. Program loading and dynamic connection
Introduction
Program Header (program header)
Program Load (program Loading)
Dynamic connection (dynamic linking)
3. C LIBRARY
C Library

________________________________________________________________

Introduction

________________________________________________________________

ELF: Executable Connection format

The executable connection format is the UNIX System Lab (USL) as the application binary interface
(Application Binary Interface (ABI) developed and released. Tool Interface Standard Committee
(TIS) selected the developing ELF standard as work on 32-bit Intel systems
Binary file formats that can be ported between systems.

Suppose a developer defines a set of binary interfaces that the ELF standard uses to support streamlined software
Development. The number of different execution interfaces should be reduced. So you can reduce the re-programmed recompile
Code.

About this piece of documentation

This document is for developers who want to create a target file or perform a file on a different operating system.
To prepare. It is divided into the following three parts:

* The first part, "Object Files" describes the elf target file format of three major
of the type.
* The second part, "Program reprint and Dynamic Connection" describes the target file information and system in the creation
The behavior of the run-time program.
* The third part, "C Language Library" lists all the symbols contained in the Libsys, the standard ANSI C
and libc, as well as the global data symbols required for LIBC to run the program.

Note: The reference X86 system has been changed to the Intel system.

________________________________________________________________

1. Target files (object file)

________________________________________________________________

========================= Preface =========================

The first section describes the format of the Iabi object file, called the Elf (executable
and linking Format). There are three main types in the object file.

* A relocatable (relocatable) file holds the code and the appropriate data to be used with other
Object file to create an executable file or a shared file.
* An executable (executable) file holds a program that is used to execute;
How exec (Ba_os) creates the program process image.
* A Shared object file holds the code and the appropriate data to be used by the following two linker
Link. The first one is the connection editor [see LD (SD_CMD)], which can be used with other relocatable and
Share the object file to create an additional object. The second one is the dynamic linker, which unites a
Executable files and other shared object files to create a process image.

An object file is created by the assembler and the linker, object that wants to run directly on the processing machine
Files are stored in binary. Programs that require abstract mechanisms, such as shell scripts,
is not accepted.

After the introductory material, the first part revolves around the format of the document and how to set up the program.
The second part also describes several components of the object file, focusing on the information necessary to execute the program.

File format

The object file participates in the program's join (creating a program) and the execution of the program (running a program).
The object file format provides a convenient and efficient way to view the contents of a file in parallel,
In their activities, different needs are reflected. Example 1-1 shows an object file with the
Organization Chart.

+ Figure 1-1: Object File format

Linking perspective Execution Perspective
============                      ==============
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 head at the beginning of the file, a roadmap (road map) was saved, describing the organization of the document.
Sections holds the information of the object file, from the connection point of view: including instructions, data,
Symbol table, reposition information, and so on. Special sections descriptions will appear in the first part of the future.
The second part discusses the paragraphs and the documents from the point of view of the program implementation.

If a program Header table exists, it tells the system how to create a
Memory image of a process. A file that is used to create a process image (to execute a program) must have a path
Sequence Header table (program header tables), the Header table is not required for relocatable files. One
The section Headers table (section Header table) contains information describing the sections of the file. Each
The section has an entry in the table, and each entry gives the section's name, size,
and other information. The file must have a section Header table during the join process, and the other object files can be
Do not have this section Header table.

Note: Although the figure shows that the program Header table appears immediately after an elf head, the section Header table follows the other
The section appears, and the fact is that the file can be different. In addition, sections and Duan (segments)
There is no particular order. Only the Elf header (elf header) is in the fixed position of the file.

Data representation
The object file format supports 8-bit, 32-bit different processors. However, it tried to work harder in the larger
or smaller systems. Therefore, the object file depicts some control data that needs to be used with the machine
Unrelated format, making it possible to identify object files and describe their content in a general way.
The remaining data in the object file is encoded using the target processor, regardless of the file
Created on the machine.

+ 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 of the object file formats are defined by the natural size of the data structure (natural size), for the relevant
The type adjustment pointer. If required, the data structure explicitly contains the 4-byte alignment of the fill
The Fill field. Make the size of the structure a multiple of 4. The data is also properly aligned from the beginning of the file.
For example, a structure that contains a ELF32_ADDR member will be aligned within the file to a 4-byte boundary.

The elf does not use bit fields for portability reasons.

========================== ELF Header ==========================

The control structure of some object files can grow, so the ELF header contains their current size.
If the object file format changes, the program may encounter large or small control structures that they do not want.
The program may also ignore additional (extra) information.
The information that treats the unknown (missing) depends on the context, and if the extension is defined, they
will be specified.

+ 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 E_shoff;
Elf32_word E_flags;
Elf32_half e_ehsize;
Elf32_half e_phentsize;
Elf32_half E_phnum;
Elf32_half e_shentsize;
Elf32_half E_shnum;
Elf32_half E_shstrndx;
} ELF32_EHDR;

* E_ident

This initial field indicates that the file is an object file and provides a machine-independent
The data that explains the contents of the file. In the following Elf identification (elf identification)
Section has more detailed information.

* E_type

The member determines the type of the object.

Name Value Meaning
====        =====  =======
Et_none 0 No file type
Et_rel 1 relocatable File
Et_exec 2 executable file
Et_dyn 3 Shared Object File
Et_core 4 CORE File
Et_loproc 0xff00 processor-specific
Et_hiproc 0xFFFF processor-specific

Although the contents of the core file are not indicated, the type Et_core is reserved.
Values from Et_loproc to Et_hiproc (including Et_hiproc) are reserved for special processors.
If necessary, other reserved variables will be used on the new object file type.

* E_machine

This member variable indicates the architecture required to run the program.

Name Value Meaning
====      =====  =======
Em_none 0 No Machine
Em_m32 1 T/WE 32100
Em_sparc 2 SPARC
Em_386 3 Intel 80386
em_68k 4 Motorola 68000
em_88k 5 Motorola 88000
em_860 7 Intel 80860
Em_mips 8 MIPS RS3000

If necessary, other reserved values will be used on the new machine type. The special processor name uses the machine name to
Differentiate them. For example, the following will be referred to the member flags using the prefix ef_; in a em_xyz machine
, flag is called a WIDGET, then it is called Ef_xyz_widget.

* E_version

This member determines the version of the object file.

Name Value Meaning
====         =====  =======
Ev_none 0 Invalid version
Ev_current 1 Current version

A value of 1 indicates the original file format, and the number of >1 is used to create the new version. Ev_current Value (above gives
The current version number, if required, will be pointed to 1.

* E_entry

This member is the virtual address of the system's first transport control, where the process starts. If the file is not
How to associate the entry point, the member will remain at 0.

* E_phoff

The member maintains the offset (in bytes) of the Program Header table in the file.
If the document does not have a program header, the member will remain at 0.

* E_shoff

The member maintains the offset (in bytes) of the section Header table (Header table) in the file
Count). If the document does not have a section Header table, the member will remain at 0.

* E_flags

The member holds a specific processor flag for the associated file.
The name of flag comes from ef_<machine>_<flag>. Take a look at the machine information "machines Information"
The definition of part of the flag.

* E_ehsize

This member holds the ELF head size, in bytes.

* E_phentsize

This member holds the size of an entry in the file's program Header table
(count in bytes). All the entrances are the same size.

* E_phnum

The member holds the number of entries in the Program Header table. Therefore, E_phentsize and E_phnum
Is the size of the table (in bytes). If there is no Program Header table,
The E_phnum variable is 0.

* E_shentsize

The member holds the size (in bytes) of the section header. A section header is in section
One entry for the Head Table (section Header table); All entrances are the same size.

* E_shnum

The member holds the number of entries in the section Header table. Therefore, e_shentsize and
The product of the E_shnum is the size (in bytes) of the section Header table.
If the file does not have a section Header table, the E_shnum value is 0.

* E_SHSTRNDX

This member holds the section Header table associated with the entry for the section name character list (section header
Table) index. If the file does not have a section name character list, the value of this variable is shn_undef.
For more information, see "Sections" and the string table below ("string table").

ELF Identification (identification)

As mentioned above, ELF provides a framework structure of object files to support multiple processors, multiple
Type of data encoding method, a variety of machine types. To support this object file family, the first few
Bytes are specified to explain how the file is interpreted, independent of the processor, regardless of what remains in the file.

The first few bytes of the ELF header (that is, the object file) coincide with the member E_ident.

+ Figure 1-4: e_ident[] Identification Indexes

Name Value Purpose
====           =====  =======
EI_MAG0 0 File Identification
EI_MAG1 1 File Identification
Ei_mag2 2 File Identification
EI_MAG3 3 File Identification
Ei_class 4 File CLASS
Ei_data 5 DATA encoding
Ei_version 6 File VERSION
Ei_pad 7 Start of padding bytes
Ei_nident Size of e_ident[]

By accessing the bytes through the index, the following variables are defined.

* EI_MAG0 to Ei_mag3

The first 4 characters of the

  file hold a magic number to determine if the file
  is the elf's target file.

Name Value Position
====       =====  ========
ELFMAG0 0x7f E_ident[ei_mag0]
ELFMAG1 ' E ' e_ident[ei_mag1]
ELFMAG2 ' L ' e_ident[ei_mag2]
ELFMAG3 ' F ' e_ident[ei_mag3]

* Ei_class

The next byte is E_ident[ei_class], which is used to determine the type of file or the ability.

Name Value Meaning
====           =====  =======
Elfclassnone 0 Invalid Class
ELFCLASS32 1 32-bit objects
ELFCLASS64 2 64-bit objects

The file format is designed to be portable in different sizes of machines, not on mainframes on small machines
The dimensions. Type ELFCLASS32 supports machines with a maximum virtual address space of up to 4GB;
The base type defined.

The type ELFCLASS64 is reserved for 64-bit system machines. Its presence indicates that the object file may
Changed, but the 64-bit format has not yet been defined. If required, other types will be defined and will be
There are different types and different sizes of data sizes.

* Ei_data

BYTE E_ident[ei_data] Specifies the encoding of the specific processor data in the object file
Way. The following encoding is currently defined.

Name Value Meaning
====           =====  =======
Elfdatanone 0 Invalid Data encoding
ELFDATA2LSB 1 See below
ELFDATA2MSB 2 See below

More information about the encoding appears below. Other values are retained and will be assigned a new encoding
Way, of course, if necessary.

* Ei_version

Byte E_ident[ei_version] Indicates the version number of the ELF header.
Now this variable must be set to ev_current as an explanation of the above e_version.

* Ei_pad

This variable identifies unused bytes that begin in E_ident. Those bytes are reserved and set to
0; The program reads them out of the object file but should be ignored. If the bytes that are not currently being used
With the new definition, the EI_PAD variable will be changed in the future.

The data encoding of a file indicates how to interpret a basic object file. In the above-mentioned
Description, the type ELFCLAS32 file uses a target file that occupies 1, 2, and 4 bytes. The following defines the
Encoding, depicted in the following diagram. The data appears in the upper-left corner.

The ELFDATA2LSB encoding specifies a complement value of 2.
The smallest meaningful byte occupies the lowest address.

+ Figure 1-5: Data Encoding elfdata2lsb

               0------+
       0x0102   |  01  |
               +------+
                0------1------+
     0x010204   |  02  |  01  |
               +------+------+
               0------1------2------3---- --+
  0x01020304   |  04  |  03  |&n