ELF Object File Format: Understanding Relocatable Files and Section Header Tables - Prof. , Papers of Programming Languages

Download ELF Object File Format: Understanding Relocatable Files and Section Header Tables - Prof. and more Papers Programming Languages in PDF only on Docsity!

I

Executable and Linkable Format (ELF)

Contents

Preface

1

OBJECT FILES

Introduction 1- ELF Header 1- Sections 1- String Table 1- Symbol Table 1- Relocation 1-

2

PROGRAM LOADING AND DYNAMIC LINKING

Introduction 2- Program Header 2- Program Loading 2- Dynamic Linking 2-

3

C LIBRARY

C Library 3-

I

Index

Index I-

Tool Interface Standards (TIS) Portable Formats Specification, Version 1.1 i

Figures and Tables

Preface

ELF: Executable and Linking Format

The Executable and Linking Format was originally developed and published by UNIX System Labora- tories (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.

Tool Interface Standards (TIS) Portable Formats Specification, Version 1.1 1

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 execut- able 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 pro- grams. 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 pro- gram). 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 Program header table ______________________^ optional _______________________ ______________________^ Section 1

... Segment 1

---

______________________^ Section^ n ... Segment 2

---

......

---

Section header table Section header table ______________________^ _______________________^ optional

An ELF header resides at the beginning and holds a ‘‘road map’’ describing the file’s organization. Sec- tions hold the bulk of object file information for the linking view: instructions, data, symbol table, reloca- tion information, and so on. Descriptions of special sections appear later in Part 1. Part 2 discusses seg- ments and the program execution view of the file.

Tool Interface Standards (TIS) Portable Formats Specification, Version 1.1 1-

ELF: Executable and Linkable Format

A program header table , if present, tells the system how to create a process image. Files used to build a pro- cess 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 link- ing 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 architec- tures. Nevertheless, it is intended to be extensible to larger (or smaller) architectures. Object files there- fore 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 encod- ing 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.

1-2 Portable Formats Specification, Version 1.1 Tool Interface Standards (TIS)

ELF: Executable and Linkable Format

e_machine This member’s value specifies the required architecture for an individual file.

____________________________________Name^ Value^ Meaning EM_NONE 0 No machine EM_M32 1 AT&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 RS ____________________________________

Other values are reserved and will be assigned to new machines as necessary. Processor-specific ELF names use the machine name to distinguish them. For example, the flags mentioned below use the prefix EF_; a flag named WIDGET for the EM_XYZ machine would be called EF_XYZ_WIDGET.

e_version This member identifies the object file version.

______________________________________Name^ Value^ Meaning EV_NONE 0 Invalid version EV_CURRENT ______________________________________ 1 Current version 

The value 1 signifies the original file format; extensions will create new versions with higher numbers. The value of EV_CURRENT, though given as 1 above, will change as necessary to reflect the current version number.

e_entry This member gives the virtual address to which the system first transfers control, thus starting the process. If the file has no associated entry point, this member holds zero.

e_phoff This member holds the program header table’s file offset in bytes. If the file has no program header table, this member holds zero.

e_shoff This member holds the section header table’s file offset in bytes. If the file has no sec- tion header table, this member holds zero.

e_flags This member holds processor-specific flags associated with the file. Flag names take the form EF_ machine _ flag. See ‘‘Machine Information’’ for flag definitions.

e_ehsize This member holds the ELF header’s size in bytes.

e_phentsize This member holds the size in bytes of one entry in the file’s program header table; all entries are the same size.

e_phnum This member holds the number of entries in the program header table. Thus the pro- duct of e_phentsize and e_phnum gives the table’s size in bytes. If a file has no pro- gram header table, e_phnum holds the value zero.

e_shentsize This member holds a section header’s size in bytes. A section header is one entry in the section header table; all entries are the same size.

e_shnum This member holds the number of entries in the section header table. Thus the product of e_shentsize and e_shnum gives the section header table’s size in bytes. If a file has no section header table, e_shnum holds the value zero.

1-4 Portable Formats Specification, Version 1.1 Tool Interface Standards (TIS)

ELF: Executable and Linkable Format

e_shstrndx This member holds the section header table index of the entry associated with the sec- tion name string table. If the file has no section name string table, this member holds the value SHN_UNDEF. See ‘‘Sections’’ and ‘‘String Table’’ below for more informa- tion.

ELF Identification

As mentioned above, ELF provides an object file framework to support multiple processors, multiple data encodings, and multiple classes of machines. To support this object file family, the initial bytes of the file specify how to interpret the file, independent of the processor on which the inquiry is made and indepen- dent of the file’s remaining contents.

The initial bytes of an ELF header (and an object file) correspond to the e_ident member.

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 16 Size of e_ident[] ___________________________________________

These indexes access bytes that hold the following values.

EI_MAG0 to EI_MAG A file’s first 4 bytes hold a ‘‘magic number,’’ identifying the file as an ELF object 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, e_ident[EI_CLASS], identifies the file’s class, or capacity.

Tool Interface Standards (TIS) Portable Formats Specification, Version 1.1 1-

ELF: Executable and Linkable Format

Encoding ELFDATA2MSB specifies 2’s complement values, with the most significant byte occupying the lowest address.

Figure 1-6: Data Encoding ELFDATA2MSB

0 0x

0 02

1 0x

0 02

1 03

2 04

3 0x

Machine Information

For file identification in e_ident, the 32-bit Intel Architecture requires the following values.

Figure 1-7: 32-bit Intel Architecture Identification, e_ident

_____________________________________^ Position^ Value e_ident[EI_CLASS] ELFCLASS e_ident[EI_DATA] _____________________________________ ELFDATA2LSB 

Processor identification resides in the ELF header’s e_machine member and must have the value EM_386.

The ELF header’s e_flags member holds bit flags associated with the file. The 32-bit Intel Architecture defines no flags; so this member contains zero.

Tool Interface Standards (TIS) Portable Formats Specification, Version 1.1 1-

Sections

An object file’s section header table lets one locate all the file’s sections. The section header table is an array of Elf32_Shdr structures as described below. A section header table index is a subscript into this array. The ELF header’s e_shoff member gives the byte offset from the beginning of the file to the sec- tion header table; e_shnum tells how many entries the section header table contains; e_shentsize gives the size in bytes of each entry.

Some section header table indexes are reserved; an object file will not have sections for these special indexes.

Figure 1-8: Special Section Indexes

__________________________^ Name^ Value SHN_UNDEF 0 SHN_LORESERVE 0xff SHN_LOPROC 0xff SHN_HIPROC 0xff1f SHN_ABS 0xfff SHN_COMMON 0xfff SHN_HIRESERVE 0xffff __________________________

SHN_UNDEF This value marks an undefined, missing, irrelevant, or otherwise meaningless section reference. For example, a symbol ‘‘defined’’ relative to section number SHN_UNDEF is an undefined symbol.

NOTE

Although index 0 is reserved as the undefined value, the section header table contains an entry for index 0. That is, if the e_shnum member of the ELF header says a file has 6 entries in the section header table, they have the indexes 0 through 5. The contents of the initial entry are specified later in this section.

SHN_LORESERVE This value specifies the lower bound of the range of reserved indexes.

SHN_LOPROC through SHN_HIPROC Values in this inclusive range are reserved for processor-specific semantics.

SHN_ABS This value specifies absolute values for the corresponding reference. For example, symbols defined relative to section number SHN_ABS have absolute values and are not affected by relocation.

SHN_COMMON Symbols defined relative to this section are common symbols, such as FORTRAN COMMON or unallocated C external variables.

SHN_HIRESERVE This value specifies the upper bound of the range of reserved indexes. The system reserves indexes between SHN_LORESERVE and SHN_HIRESERVE, inclusive; the values do not reference the section header table. That is, the section header table does not contain entries for the reserved indexes.

Sections contain all information in an object file, except the ELF header, the program header table, and the section header table. Moreover, object files’ sections satisfy several conditions.

1-8 Portable Formats Specification, Version 1.1 Tool Interface Standards (TIS)

ELF: Executable and Linkable Format

sh_info This member holds extra information, whose interpretation depends on the section type. A table below describes the values.

sh_addralign Some sections have address alignment constraints. For example, if a section holds a doubleword, the system must ensure doubleword alignment for the entire section. That is, the value of sh_addr must be congruent to 0, modulo the value of sh_addralign. Currently, only 0 and positive integral powers of two are allowed. Values 0 and 1 mean the section has no alignment constraints.

sh_entsize Some sections hold a table of fixed-size entries, such as a symbol table. For such a sec- tion, this member gives the size in bytes of each entry. The member contains 0 if the section does not hold a table of fixed-size entries.

A section header’s sh_type member specifies the section’s semantics.

Figure 1-10: Section Types, sh_type

______________________________^ Name^ Value SHT_NULL 0 SHT_PROGBITS 1 SHT_SYMTAB 2 SHT_STRTAB 3 SHT_RELA 4 SHT_HASH 5 SHT_DYNAMIC 6 SHT_NOTE 7 SHT_NOBITS 8 SHT_REL 9 SHT_SHLIB 10 SHT_DYNSYM 11 SHT_LOPROC 0x SHT_HIPROC 0x7fffffff SHT_LOUSER 0x SHT_HIUSER 0xffffffff ______________________________

SHT_NULL This value marks the section header as inactive; it does not have an associated section. Other members of the section header have undefined values.

SHT_PROGBITS The section holds information defined by the program, whose format and meaning are determined solely by the program.

SHT_SYMTAB and SHT_DYNSYM These sections hold a symbol table. Currently, an object file may have only one sec- tion of each type, but 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 unneces- sary for dynamic linking. Consequently, an object file may also contain a SHT_DYNSYM section, which holds a minimal set of dynamic linking symbols, to save space. See ‘‘Symbol Table’’ below for details.

1-10 Portable Formats Specification, Version 1.1 Tool Interface Standards (TIS)

ELF: Executable and Linkable Format

SHT_STRTAB The section holds a string table. An object file may have multiple string table sections. See ‘‘String Table’’ below for details.

SHT_RELA The section holds relocation entries with explicit addends, such as type Elf32_Rela for the 32-bit class of object files. An object file may have multiple relocation sections. See ‘‘Relocation’’ below for details.

SHT_HASH The section holds a symbol hash table. All objects participating in dynamic linking must contain a symbol hash table. Currently, an object file may have only one hash table, but this restriction may be relaxed in the future. See ‘‘Hash Table’’ in Part 2 for details.

SHT_DYNAMIC The section holds information for dynamic linking. Currently, an object file may have only one dynamic section, but this restriction may be relaxed in the future. See ‘‘Dynamic Section’’ in Part 2 for details.

SHT_NOTE The section holds information that marks the file in some way. See ‘‘Note Section’’ in Part 2 for details.

SHT_NOBITS A 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_REL The section holds relocation entries without explicit addends, such as type Elf32_Rel for the 32-bit class of object files. An object file may have multiple reloca- tion sections. See ‘‘Relocation’’ below for details.

SHT_SHLIB This section type is reserved but has unspecified semantics. Programs that contain a section of this type do not conform to the ABI.

SHT_LOPROC through SHT_HIPROC Values in this inclusive range are reserved for processor-specific semantics.

SHT_LOUSER This value specifies the lower bound of the range of indexes reserved for application programs.

SHT_HIUSER This value specifies the upper bound of the range of indexes reserved for application programs. Section types between SHT_LOUSER and SHT_HIUSER may be used by the application, without conflicting with current or future system-defined section types.

Other section type values are reserved. As mentioned before, the section header for index 0 (SHN_UNDEF) exists, even though the index marks undefined section references. This entry holds the fol- lowing.

Figure 1-11: Section Header Table Entry: Index 0

______________________________________________________^ Name^ Value^ Note sh_name 0 No name sh_type SHT_NULL Inactive sh_flags 0 No flags sh_addr 0 No address sh_offset 0 No file offset sh_size (^)  0 No size

Tool Interface Standards (TIS) Portable Formats Specification, Version 1.1 1-

ELF: Executable and Linkable Format

Figure 1-13: sh_link and sh_info Interpretation

sh_type sh_link sh_info

---

The section header index of the string table used by entries in the section.

SHT_DYNAMIC 0

______________________________________________________________________

The section header index of the symbol table to which the hash table applies.

SHT_HASH 0

______________________________________________________________________

SHT_REL

SHT_RELA

The section header index of the associated symbol table.

The section header index of the section to which the ______________________________________________________________________relocation applies. SHT_SYMTAB SHT_DYNSYM

The section header index of the associated string table.

One greater than the sym- bol table index of the last local symbol (binding ______________________________________________________________________^ STB_LOCAL). other ______________________________________________________________________ SHN_UNDEF 0 

Special Sections

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

Figure 1-14: Special Sections

____________________________________________________________^ Name^ Type^ Attributes .bss SHT_NOBITS SHF_ALLOC + SHF_WRITE .comment SHT_PROGBITS none .data SHT_PROGBITS SHF_ALLOC + SHF_WRITE .data1 SHT_PROGBITS SHF_ALLOC + SHF_WRITE .debug SHT_PROGBITS none .dynamic SHT_DYNAMIC see below .dynstr SHT_STRTAB SHF_ALLOC .dynsym SHT_DYNSYM SHF_ALLOC .fini SHT_PROGBITS SHF_ALLOC + SHF_EXECINSTR .got SHT_PROGBITS see below .hash SHT_HASH SHF_ALLOC .init SHT_PROGBITS SHF_ALLOC + SHF_EXECINSTR .interp SHT_PROGBITS see below .line SHT_PROGBITS none .note SHT_NOTE none .plt SHT_PROGBITS see below .rel name (^) SHT_REL see below

Tool Interface Standards (TIS) Portable Formats Specification, Version 1.1 1-

ELF: Executable and Linkable Format

Figure 1-14: Special Sections (continued )

.rela name SHT_RELA see below .rodata SHT_PROGBITS SHF_ALLOC .rodata1 SHT_PROGBITS SHF_ALLOC .shstrtab SHT_STRTAB none .strtab SHT_STRTAB see below .symtab SHT_SYMTAB see below .text SHT_PROGBITS SHF_ALLOC + SHF_EXECINSTR ____________________________________________________________

.bss This section holds uninitialized data that contribute to the program’s memory image. By definition, the system initializes the data with zeros 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 and .data These sections hold initialized data that contribute to the program’s memory image.

.debug This section holds information for symbolic debugging. The contents 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 Part 2 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 Part 2 for more information.

.dynsym This section holds the dynamic linking symbol table, as ‘‘Symbol Table’’ describes. See Part 2 for more information.

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

.got This section holds the global offset table. See ‘‘Special Sections’’ in Part 1 and ‘‘Global Offset Table’’ in Part 2 for more information.

.hash This section holds a symbol hash table. See ‘‘Hash Table’’ in Part 2 for more information.

.init This section holds executable instructions that contribute to the process initialization code. That is, when a program starts to run, the system arranges to execute the code in this sec- tion before calling the main program entry point (called main for C programs).

.interp This section holds the path name of a program interpreter. If the file has a loadable seg- ment that includes the section, the section’s attributes will include the SHF_ALLOC bit; oth- erwise, that bit will be off. See Part 2 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.

1-14 Portable Formats Specification, Version 1.1 Tool Interface Standards (TIS)