Executable and Linkable Format (ELF)

8/14/2019 Executable and Linkable Format (ELF)

1/60

I

Executable and Linkable Format (ELF)


2/60

Contents

Preface

1 OBJECT FILESIntroduction 1-1ELF Header 1-3

Sections 1-8

String Table 1-16

Symbol Table 1-17

Relocation 1-21

2 PROGRAM LOADING AND DYNAMIC LINKINGIntroduction 2-1Program Header 2-2

Program Loading 2-7

Dynamic Linking 2-10

3 C LIBRARYC Library 3-1

I IndexIndex I-1

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


3/60

ELF: Executable and Linkable Format

ii Portable Formats Spe cification , Version 1.1 Tool Interface Standards (TIS)


4/60

Figures and Tables

Figure 1-1: Object File Format 1-1

Figure 1-2: 32-Bit Data Types 1-2

Figure 1-3: ELF Header 1-3

Figure 1-4: e_ident[ ] Identification Indexes 1-5

Figure 1-5: Data Encoding ELFDATA2LSB 1-6

Figure 1-6: Data Encoding ELFDATA2MSB 1-6

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

Figure 1-8: Special Section Indexes 1-8

Figure 1-9: Section Header 1-9

Figure 1-10: Section Types, sh_type 1-10

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

Figure 1-12: Section Attribute Flags, sh_flags 1-12

Figure 1-13: sh_link and sh_info Interpretation 1-13Figure 1-14: Special Sections 1-13

Figure 1-15: String Table Indexes 1-16

Figure 1-16: Symbol Table Entry 1-17

Figure 1-17: Symbol Binding, ELF32_ST_BIND 1-18

Figure 1-18: Symbol Types, ELF32_ST_TYPE 1-19

Figure 1-19: Symbol Table Entry: Index 0 1-20

Figure 1-20: Relocation Entries 1-21

Figure 1-21: Relocatable Fields 1-22

Figure 1-22: Relocation Types 1-23

Figure 2-1: Program Header 2-2

Figure 2-2: Segment Types, p_type 2-3

Figure 2-3: Note Information 2-4

Figure 2-4: Example Note Segment 2-5

Figure 2-5: Executable File 2-7Figure 2-6: Program Header Segments 2-7

Figure 2-7: Process Image Segments 2-8

Figure 2-8: Example Shared Object Segment Addresses 2-9

Figure 2-9: Dynamic Structure 2-12

Figure 2-10: Dynamic Array Tags, d_tag 2-12

Figure 2-11: Global Offset Table 2-17

Figure 2-12: Absolute Procedure Linkage Table 2-17

Figure 2-13: Position-Independent Procedure Linkage Table 2-18

Figure 2-14: Symbol Hash Table 2-19

Figure 2-15: Hashing Function 2-20

Figure 3-1: libc Contents, Names without Synonyms 3-1

Figure 3-2: libc Contents, Names with Synonyms 3-1

Figure 3-3: libc Contents, Global External Data Symbols 3-2

Tool Interface Standards (TIS) Portable Formats Spe cification , Version 1.1 iii


5/60

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 Ap plication Binary Interface (ABI). The Tool Interface Standar ds committee

(TIS) has selected the evolving ELF standard as a p ortable object file format th at w orks on 32-bit IntelArchitecture environments for a variety of operating systems.

The ELF standard is intended to streamline software d evelopm ent by p roviding developers with a set of

binary interface definitions that extend across mu ltiple operating env ironments. This shou ld red uce the

nu mber of d ifferent interface imp lementations, thereby redu cing the need for recoding and recomp iling

code.

About This Document

This docum ent is intended for developers w ho are creating object or executab le files on various 32-bit

environment operating systems. It is divided into the following three parts:

Par t 1, Object Files describes th e ELF object file form at for th e thr ee ma in typ es of object files.

Part 2, Program Loading an d Dynam ic Linking describes the object file information and system

actions that create runn ing program s.

Par t 3, C Library lists the symbols contained in libsys, the standard AN SI 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 Spe cification , Version 1.1 1


6/60

1 OBJECT FILES

Introduction 1-1File Format 1-1

Data Representation 1-2

ELF Header 1-3ELF Identification 1-5

Machine Information 1-7

Sections 1-8Special Sections 1-13

String Table 1-16

Symbol Table 1-17Symbol Values 1-20

Relocation 1-21Relocation Types 1-22



7/60

Introduction

Part 1 d escribes the iABI object file form at, called ELF (Executab le and Linking Format). There are th ree

main types of object files.

A relocatable file holds code and da ta suitable for linking w ith other object files to create an execut-

able or a sha red object file.

An executable file holds a progr am su itable for execution; the file specifies how exec(BA_OS) createsa programs process image.

A shared object file holds code and d ata suitable for linking in two contexts. First, the link editor [see

ld(SD_CMD)] may p rocess it w ith other r elocatable and shared object files to create another objectfile. Second, the dynam ic 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 d irectly on a p rocessor. Program s that requ ire other abstract machines, such as shell scripts, are

excluded.

After the introdu ctory m aterial, Part 1 focuses on the file format an d how it pertains to building pro-

gram s. Part 2 also describes par ts of the object file, concentrating on the information n ecessary to executea program.

File Format

Object files participate in program linking (building a program) and program execution (runn ing a p ro-

gram ). For convenience and efficiency, the object file format p rovides para llel views of a files contents,

reflecting the d iffering n eeds of these activities. Figure 1-1 shows an object files organ ization.

Figure 1-1: Object File Format

Linking View Execution View_ _____________________ _______________________ELF head er ELF head er_ _____________________ _______________________

Program header table Program header table

optional_ _____________________ _______________________Section 1______________________

. . . Segmen t 1_ _____________________ _______________________

Section n______________________. . . Segmen t 2

_ _____________________ _______________________. . . . . .

_ _____________________ _______________________Section head er table Section head er table

optional_ _____________________ _______________________

An ELF headerresides at the beginn ing and holds a road map describing the files organization. Sec-

tions hold the bu lk of object file information for the linking view: instructions, data, sym bol 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-1


8/60


A program header table, if present, tells the system how to create a process image. Files used to build a p ro-

cess image (execute a program ) mu st have a program head er table; relocatable files do not need one. A

section header tablecontains information d escribing the files sections. Every section ha s an entry in th e

table; each entry gives information su ch as the section name, the section size, etc. Files used d uring link-

ing mu st have a section head er table; other object files may or m ay not have one.

NOTE

Although the figure shows the program header table immediately after the ELF header, and the sectionheader table following the sections, actual files may differ. Moreover, sections and segments have nospecified order. Only the ELF header has a fixed position in the file.

Data Representation

As d escribed here, the ob ject file formatsup por ts various p rocessors with 8-bit bytes and 32-bit architec-

tur es. 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 interpr et their contents in a common w ay. Remaining data in an object file use the encod-ing of the target processor, regardless of the machine on wh ich the file was created.

Figure 1-2: 32-Bit Data Types

Nam e Size Alignment Purp ose_____________________________________________________________Elf32_Addr 4 4 Unsigned program add ress

Elf32_Half 2 2 Unsigned med ium 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 stru ctures that the object file format defines follow the natu ral size and alignmen t gu idelines

for the relevant class. If necessary, data structu res contain explicit pad ding to ensure 4-byte alignmen t for

4-byte objects, to force structure sizes to a m ultiple of 4, etc. Data also hav e suitable alignment from the

beginning of the file. Thus, for examp le, a structure containing an Elf32_Addr mem ber will be aligned

on a 4-byte bound ary w ithin the file.

For por tability reasons, ELF uses no bit-fields.

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


9/60

ELF Header

Some object file control structures can grow , because the ELF header contains th eir actual sizes. If the

object file format changes, a progr am m ay encoun ter control structures that are larger or sm aller than

expected. Program s migh t therefore ignore extra information. The treatmen t of missing informa-

tion depend s on context and will be specified w hen 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 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 The initial bytes mark the file as an object file and p rovide m achine-ind ependen t data

with w hich to d ecode and interpret the files contents. Complete descriptions appear

below , in ELF Identificat ion.

e_type This member identifies the object file type.

Nam e 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 core file contents are unspecified, type ET_CORE is reserved to mark the

file. Values from ET_LOPROC through ET_HIPROC (inclusive) are reserved forprocessor-specific seman tics. Other valu es are reserved an d w ill be assigned to new

object file types as necessary.



10/60


e_machine This members value specifies the requ ired architecture for an ind ividual file.

Nam e Value Meaning____________________________________EM_NONE 0 No machine

EM_M32 1 AT&T WE 32100

EM_SPARC 2 SPARCEM_386 3 Intel 80386

EM_68K 4 Motorola 68000

EM_88K 5 Motorola 88000

EM_860 7 Intel 80860

EM_MIPS 8 MIPS RS3000____________________________________

Other values are reserved and will be assigned to new machines as necessary.

Processor-specific ELF names use the machine nam e to distingu ish them. For examp le,

the flags mentioned below u se 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 forma t; extensions will create new versions with

higher numbers. The value ofEV_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 ho lds zero.

e_phoff This member hold s the progr am header tab les file offset in bytes. If the file has no

program header table, this member holds zero.

e_shoff This member holds th e section h eader tables file offset in bytes. If the file has no sec-

tion header table, this member holds zero.

e_flags This mem ber holds pr ocessor-specific flags associated w ith the file. Flag nam es take

the form EF_machine_flag. See Machine Inform ation for flag definitions.

e_ehsize This member holds th e ELF header s size in bytes.

e_phentsize This member h olds the size in bytes of one entry in the files prog ram h eader table; all

entries are the same size.

e_phnum This member holds the nu mber of entries in the program header table. Thus the pro-

du ct ofe_phentsize an d e_phnum gives the tables size in bytes. If a file has no p ro-

gram head er table, e_phnum holds the value zero.

e_shentsize This member hold s a section head ers size in bytes. A section head er is one entry inthe section head er table; all entries are the same size.

e_shnum This member h olds the num ber of entries in the section head er table. Thus the prod uct

ofe_shentsize and e_shnum gives the section header tables size in bytes. If a file

has no section header table, e_shnum holds the value zero.



11/60


e_shstrndx This member hold s the section head er table ind ex of the entry associated with the sec-

tion nam e string table. If the file has no section nam e string table, this mem ber 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 m ultiple classes of machines. To suppor t this object file family, the initial bytes of the file

specify how to interpret the file, ind epend ent of the processor on wh ich the inqu iry is mad e and indepen-

den t of the files remaining contents.

The initial bytes of an ELF head er (and an object file) correspon d to the e_ident member.

Figure 1-4: e_ident[ ] Identification Indexes

Nam e Value Purp ose___________________________________________EI_MAG0 0 File identification

EI_MAG1 1 File identification



EI_CLASS 4 File class

EI_DATA 5 Data encoding

EI_VERSION 6 File version

EI_PAD 7 Start of pad ding bytes

EI_NIDENT 16 Size ofe_ident[]___________________________________________

These indexes access bytes that hold the following va lues.

EI_MAG0 to EI_MAG3

A files 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 files class, or capacity.



12/60


Nam e Value Meaning______________________________________ELFCLASSNONE 0 Invalid class

ELFCLASS32 1 32-bit objects

ELFCLASS64 2 64-bit objects______________________________________

The file format is designed to be por table among m achines of various sizes, withou t

imposing the sizes of the largest machine on th e smallest. Class ELFCLASS32 supports

machines w ith files and virtual ad dr ess spaces up to 4 gigabytes; it uses the basic types

defined above.

Class ELFCLASS64 is reserved for 64-bit architectures. Its appearance here shows how

the object file may change, but the 64-bit format is otherwise un specified. Other classes

will be defined a s necessary, with d ifferent basic types and sizes for object file data.

EI_DATA Byte e_ident[EI_DATA] specifies the data encoding of the pr ocessor-specific da ta in

the object file. The following encodings are curren tly defined .

Nam e Value Meaning____________________________________________ELFDATANONE 0 Invalid d ata encoding

ELFDATA2LSB 1 See below

ELFDATA2MSB 2 See below____________________________________________

More information on these encodings appears below. Other values are reserved an d

will be assigned to new encodings as necessary.

EI_VERSION Byte e_ident[EI_VERSION] specifies the ELF head er version nu mber. Cur rently, this

value must be EV_CURRENT , as explained abov e for e_version .

EI_PAD This value m arks the beginning of the unu sed bytes in e_ident . These bytes are

reserved and set to zero; program s that read object files should ignore them. The value

ofEI_PAD will change in th e future if currently un used bytes are given m eanings.

A files data en coding sp ecifies how to interpr et the basic objects in a file. As described above, class

ELFCLASS32 files use objects that occupy 1, 2, and 4 bytes. Und er the defin ed encod ings, objects arerepresented as shown below. Byte num bers appear in the up per left corners.

Encoding ELFDATA2LSB specifies 2s complem ent valu es, with the least significant byte occupy ing the

lowest address.

Figure 1-5: Data Encoding ELFDATA2LSB

010

0x01

020

011

0x0102

040

031

022

013

0x01020304



13/60


Encoding ELFDATA2MSB specifies 2s complemen t values, with th e most significant byte occup ying the

lowest address.

Figure 1-6: Data Encoding ELFDATA2MSB

010

0x01

010

021

0x0102

010

021

032

043

0x01020304

Machine Information

For file identification in e_ident , the 32-bit Intel Architectur e requ ires the following valu es.

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

Position Value_____________________________________e_ident[EI_CLASS] ELFCLASS32

e_ident[EI_DATA] ELFDATA2LSB_____________________________________

Processor identification resides in the ELF headers e_machine member and must have the value

EM_386 .

The ELF headers e_flags mem ber holds bit flags associated w ith the file. The 32-bit Intel Architectur e

defin es no flags; so this member contains zero.



14/60

Sections

An object files section head er table lets one locate all the files sections. The section head er table is an

array ofElf32_Shdr structu res as described below. A section header table index is a subscript into this

array. The ELF head ers e_shoff mem ber gives the byte offset from the beginn ing of the file to the sec-

tion header table; e_shnum tells how m any entr ies the section head er table contains; e_shentsize

gives the size in bytes of each entry.Some section head er table indexes are reserved ; an object file will not hav e sections for these special

indexes.

Figure 1-8: Special Section Indexes

Name Value__________________________SHN_UNDEF 0

SHN_LORESERVE 0xff00

SHN_LOPROC 0xff00

SHN_HIPROC 0xff1f

SHN_ABS 0xfff1

SHN_COMMON 0xfff2

SHN_HIRESERVE 0xffff__________________________

SHN_UNDEF This value marks an undefined, missing, irrelevant, or otherwise meaningless section

reference. For example, a sym bol defin ed relative to section nu mber SHN_UNDEF

is an un defined sym bol.

NOTE

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

SHN_LORESERVE This value specifies the lower boun d of the range of reserved ind exes.

SHN_LOPROC through SHN_HIPROC

Values in this inclusive range are reserved for processor-specific seman tics.

SHN_ABS This value specifies absolute values for the correspon ding reference. For examp le,

symbols defined relative to section num ber SHN_ABS have absolute values and are

not affected by relocation.

SHN_COMMON Symbols defined relative to this section are comm on sym bols, such as FORTRAN

COMMON or unallocated C external variables.

SHN_HIRESERVE This value specifies the up per bound of the range of reserved ind exes. The system

reserves indexes between SHN_LORESERVE an d SHN_HIRESERVE , inclusive; the

values do not reference the section head er table. That is, the section head er tabledoes notcontain entries for the reserved indexes.

Sections contain all information in an object file, except the ELF head er, the prog ram h eader table, and the

section h eader table. Moreover, object files sections satisfy several conditions.



15/60


Every section in an ob ject file has exactly one section header describing it. Section headers m ay

exist that d o not have a section.

Each section occupies one contiguou s (possibly emp ty) sequence of bytes within a fi le.

Sections in a file may not overlap . No byte in a file resides in more than on e section.

An object file may hav e inactive space. The various header s and the sections might not cover

every byte in an object file. The contents of the inactive data are un specified.

A section header has the following structure.

Figure 1-9: Section Header

typedef struct {

Elf32_Word sh_name;

Elf32_Word sh_type;

Elf32_Word sh_flags;

Elf32_Addr sh_addr;

Elf32_Off sh_offset;

Elf32_Word sh_size;

Elf32_Word sh_link;

Elf32_Word sh_info;

Elf32_Word sh_addralign;

Elf32_Word sh_entsize;

} Elf32_Shdr;

sh_name This member sp ecifies the nam e of the section. Its value is an ind ex into the section

header string table section [see String Table below], giving the location of a null-

terminated string.

sh_type This member categorizes the sections contents an d semantics. Section types and their

descriptions app ear below.

sh_flags Sections sup por t 1-bit flags that describe miscellaneous attributes. Flag definitions

appear below.

sh_addr If the section w ill app ear in the m emory im age of a process, this mem ber gives the

addr ess at wh ich the sections first byte should reside. Otherw ise, the mem ber con-

tains 0.

sh_offset This members value gives the byte offset from the beginning o f the file to the first

byte in the section. One section type, SHT_NOBITS described below, occup ies no

space in the file, and its sh_offset mem ber locates the conceptu al placement in the

file.

sh_size This member gives the sections size in bytes. Unless the section type is

SHT_NOBITS , the section occupies sh_size bytes in the file. A section of type

SHT_NOBITS may h ave a non -zero size, but it occup ies no space in the file.

sh_link This member holds a section head er table ind ex link, whose interpretation d epend s

on the section type. A table below describes the values.



16/60


sh_info This member holds extra information, w hose interpretation d epend s on the section

type. A table below describes the values.

sh_addralign Some sections have ad dr ess alignm ent constraints. For examp le, if a section holds a

dou bleword , the system m ust ensure d oubleword alignmen t for the entire section.

That is, the value ofsh_addr mu st be congruent to 0, mod ulo the value ofsh_addralign . Currently, only 0 and positive integral pow ers of two are allowed.

Values 0 and 1 mean the section has no alignm ent constraints.

sh_entsize Some sections hold a table of fixed-size entries, such as a sym bol table. For such a sec-

tion, this member g ives the size in bytes of each entry. The mem ber contains 0 if the

section d oes not ho ld a tab le of fixed-size entries.

A section head ers sh_type mem ber specifies the sections seman tics.

Figure 1-10: Section Types, sh_type

Name Value______________________________

SHT_NULL 0SHT_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 0x70000000

SHT_HIPROC 0x7fffffffSHT_LOUSER 0x80000000

SHT_HIUSER 0xffffffff______________________________

SHT_NULL This value marks the section head er as inactive; it does not have an associated section.

Other mem bers of the section head er have un defined values.

SHT_PROGBITS The section holds information defined by the pr ogram, wh ose format and meaning are

determined solely by the program .

SHT_SYMTAB an d SHT_DYNSYM

These sections hold a sym bol table. Cur rently, an object file may have only one sec-tion of each type, but th is restriction may be relaxed in the future. Typically,

SHT_SYMTAB pr ovides symbols for link editing, though it may also be used for

dynam ic linking. As a complete symbol table, it may contain man y symbols unneces-

sary for dynamic linking. Consequ ently, an object file may also contain a

SHT_DYNSYM section, wh ich hold s a minimal set of dynam ic linking symbols, to save

space. See Symbol Table below for de tails.



17/60


SHT_STRTAB The section holds a string table. An object file may have mu ltiple string table sections.

See String Table below for d etails.

SHT_RELA The section holds relocation entries with explicit add end s, such as type Elf32_Rela

for the 32-bit class of object files. An object file may have mu ltiple relocation sections.

See Relocation below for d etails.

SHT_HASH The section holds a symbol hash table. All objects par ticipating in dynam ic linking

mu st contain a symbol hash table. Cur rently, an object file may have only one hash

table, but th is restriction m ay be r elaxed in the futu re. See Hash Table in Part 2 for

details.

SHT_DYNAMIC The section holds information for dynamic linking. Cur rently, an object file may have

only one dynam ic section, but th is restriction m ay be relaxed in the futu re. See

Dyn am ic Section in Part 2 for d etails.

SHT_NOTE The section h olds information that m arks the file in some w ay. See Note Section in

Part 2 for d etails.

SHT_NOBITS A section of this type occupies no space in the file bu t otherw ise resembles

SHT_PROGBITS . Although this section contains no bytes, the sh_offset member

contains the conceptu al file offset.

SHT_REL The section holds relocation entries without explicit add end s, such as typ e

Elf32_Rel for the 32-bit class of object files. An ob ject file may hav e mu ltiple reloca-

tion sections. See Relocation below for det ails.

SHT_SHLIB This section type is reserved bu t has unspecified seman tics. Program s 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 ind exes reserved for application

programs.

SHT_HIUSER This value specifies the up per bou nd of the range of ind exes reserved for application

prog ram s. Section types between SHT_LOUSER an d 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 head er for index 0

(SHN_UNDEF) exists, even thou gh the index marks undefin ed section references. This entry hold s the fol-

lowing.

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

Nam e Value Note______________________________________________________sh_name 0 No namesh_type SHT_NULL Inactive

sh_flags 0 No flags

sh_addr 0 No add ress

sh_offset 0 No file offset

sh_size 0 No size



18/60


Figure 1-11: Section Header Table Entry: Index 0 (continued )

sh_link SHN_UNDEF No link information

sh_info 0 No auxiliary information

sh_addralign 0 No alignmentsh_entsize 0 No entries______________________________________________________

A section head ers sh_flags mem ber holds 1-bit flags that describe the sections attributes. Defined

values app ear below; other values are reserved.

Figure 1-12: Section Attribute Flags, sh_flags

Name Value_______________________________SHF_WRITE 0x1

SHF_ALLOC 0x2

SHF_EXECINSTR 0x4SHF_MASKPROC 0xf0000000_______________________________

If a flag bit is set in sh_flags , the attr ibute is on for the section . Otherw ise, the attr ibute is off or

does not app ly. Und efined attributes are set to zero.

SHF_WRITE The section contains data that should be writable during process execution.

SHF_ALLOC The section occup ies mem ory du ring process execution. Some control sections do

not reside in the mem ory im age of an object file; this attribute is off for those sections.

SHF_EXECINSTR The section contains executable m achine instructions.

SHF_MASKPROC All bits includ ed in th is mask are reserved for processor-specific semantics.

Two m embers in the section header, sh_link an d sh_info , hold special information, dep ending on

section typ e.



19/60


Figure 1-13: sh_link and sh_info Interpretation

sh_type sh_link sh_info______________________________________________________________________The section head er index of

the string table used byentries in the section.

SHT_DYNAMIC 0

______________________________________________________________________The section head er index of

the symbol table to wh ich

the hash table applies.

SHT_HASH 0

______________________________________________________________________SHT_REL

SHT_RELA

The section head er index of

the associated symbo l table.


the section to which the

relocation ap plies.______________________________________________________________________SHT_SYMTAB

SHT_DYNSYM


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 pr ogram an d control information. Sections in the list below are used by the system

and have the indicated types and attributes.

Figure 1-14: Special Sections

Nam e 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

.relname SHT_REL see below



20/60


Figure 1-14: Special Sections (continued )

.relaname 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 un initialized da ta that contribu te to the progr ams mem ory image. By

definition, the system initializes the data with zeros wh en the pr ogram begins to run. The

section occup ies no file space, as ind icated by the section type, SHT_NOBITS .

.comment This section holds version control information.

.data an d .data1These sections hold initialized data that contribute to the programs memory image.

.debug This section holds informa tion for symbo lic debugg ing. The contents are un specified.

.dynamic This section hold s dyn amic linking information. The sections attributes will include the

SHF_ALLOC bit. Whether the SHF_WRITE bit is set is processor sp ecific. See Part 2 for

more information.

.dynstr This section hold s strings needed for dynamic linking, most commonly the strings that

repr esent the nam es associated with sym bol table entries. See Part 2 for more inform ation.

.dynsym This section holds the dynamic linking sym bol table, as Symbol Table describes. See

Part 2 for mor e information.

.fini This section holds executab le instru ctions tha t contribute to the p rocess term ination code.That is, wh en a pr ogram exits norm ally, the system arranges to execute the code in this

section.

.got This section holds the g lobal offset table. See Special Sections in Par t 1 and Global

Offset Table in Part 2 for more information.

.hash This section holds a symbo l hash table. See Hash Table in Part 2 for more inform ation.

.init This section holds executab le instru ctions that contribute to th e process initialization code.

That is, when a p rogram starts to run , the system arranges to execute the code in this sec-

tion before calling th e main p rogram entry p oint (called main for C program s).

.interp This section hold s the path nam e of a progr am interp reter. If the file has a loadab le seg-

men t that includ es the section, the sections attributes w ill includ e the SHF_ALLOC bit; oth-

erwise, that bit w ill be off. See Part 2 for more information.

.line This section hold s line nu mber inform ation for symbolic debu gging, wh ich describes the

correspond ence between the source program and the machine code. The contents are

unspecified.



21/60


.note This section holds information in the format th at Note Section in Part 2 describes.

.plt This section hold s the pr ocedur e linkage tab le. See Special Sections in Part 1 and Pro-

cedure Linkage Table in Part 2 for more inform ation.

.relname and .relaname

These sections hold r elocation inform ation , as Relocation below d escribes. If the file has

a loadable segment th at includes relocation, the sections attributes will includ e the

SHF_ALLOC bit; otherw ise, that bit w ill be off. Conven tionally, name is sup plied by the

section to which the relocations app ly. Thus a relocation section for .text normally

would have the name .rel.text or .rela.text .

.rodata an d .rodata1

These sections hold read -only data that typ ically contribu te to a non-writable segment in

the p rocess image. See Program Header in Part 2 for more information.

.shstrtab This section hold s section nam es.

.strtab This section hold s strings, most comm only the strings that rep resent the nam es associated

with symbol table entries. If the file has a loadable segment that includ es the symbol string

table, the sections attributes will includ e the SHF_ALLOC bit; otherwise, that bit w ill be off.

.symtab This section hold s a symbol table, as Symbol Table in this section describes. If the file

has a loadable segment that includ es the symbol table, the sections attributes will include

the SHF_ALLOC bit; otherwise, that bit w ill be off.

.text This section holds the text, or executable instructions, of a pr ogram .

Section names w ith a d ot (.) prefix are reserved for the system, although app lications may use these sec-

tions if their existing meanings are satisfactory. Applications may u se names without the p refix to avoid

conflicts with system sections. The object file format lets one define sections not in the list above. An

object file may hav e more than one section with the sam e name.

Section names reserved for a processor architectur e are formed by placing an abb reviation of the architec-

ture nam e ahead of the section nam e. The name should be taken from the architecture nam es used fore_machine. For instance .FOO.psect is the psect section d efined by the FOO architecture. Existing

extensions are called by their historical names.

Pre-existing Extensions________________________

.sdata .tdesc

.sbss .lit4

.lit8 .reginfo

.gptab .liblist

.conflict



22/60

String Table

String table sections hold nu ll-termina ted character sequences, comm only called strings. The object file

uses these strings to repr esent symbol and section nam es. One references a string as an ind ex into the

string table section. The first byte, which is index zero, is defin ed to hold a nu ll character. Likewise, a

string tables last byte is defined to hold a nu ll character, ensu ring nu ll termination for all strings. A

string w hose index is zero specifies either no nam e or a null name, depend ing on the context. An emp tystring table section is perm itted; its section h eader s sh_size member wou ld contain zero. Non-zero

indexes are invalid for an emp ty string table.

A section head ers sh_name mem ber holds an ind ex into the section header string table section, as desig-

nated by the e_shstrndx mem ber of the ELF head er. The following figures show a string table with 25

bytes and the strings associated with v arious indexes.

Ind ex + 0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9______________________________________________________0 \0 n a m e . \0 V a r______________________________________________________

10 i a b l e \0 a b l e______________________________________________________20 \0 \0 x x \0______________________________________________________

Figure 1-15: String Table Indexes

Index String__________________0 none

1 name.

7 Variable

11 able

16 able

24 null string__________________

As the example show s, a string table index may refer to any byte in the section. A string may ap pear

mor e than on ce; references to substrings may exist; and a single string may be referenced m ultiple times.Unreferenced strings also are allowed.



23/60

Symbol Table

An object files symbol table holds inform ation need ed to locate and relocate a program s symbolic

defin itions and r eferences. A symbol table index is a subscript into this array. Index 0 both designa tes

the first entry in the table and serves as the und efined symbol index. The contents of the initial entry are

specified later in th is section.

Name Value___________________STN_UNDEF 0___________________

A symbo l table entry ha s the following forma t.

Figure 1-16: Symbol Table Entry

typedef struct {

Elf32_Word st_name;

Elf32_Addr st_value;

Elf32_Word st_size;

unsigned char st_info;unsigned char st_other;

Elf32_Half st_shndx;

} Elf32_Sym;

st_name This member h olds an ind ex into the object files symbol string table, wh ich hold s the

character representa tions of the symbol names. If the value is non-zero, it represen ts a

string table index that gives the symbo l nam e. Other wise, the symbol table entry has no

name.

NOTE

External C symbols have the same names in C and object files symbol tables.

st_value This mem ber gives the value of the associated sym bol. Depen ding on th e context, this

may be an absolute value, an addr ess, etc.; details app ear below.

st_size Many sym bols have associated sizes. For example, a data objects size is the nu mber of

bytes contained in the object. This member hold s 0 if the symbol has no size or an

unknown size.

st_info This mem ber specifies the symbols type and bind ing attributes. A list of the values and

meanings app ears below. The following code shows how to manipu late the values.

#define ELF32_ST_BIND(i) ((i)>>4)

#define ELF32_ST_TYPE(i) ((i)&0xf)

#define ELF32_ST_INFO(b,t) (((b)


24/60


st_other This member currently holds 0 and has no defined meaning.

st_shndx Every symbol table entry is defin ed in relation to some section; this member h olds the

relevant section head er table ind ex. As Figur e 1-7 and the related text describe, some

section ind exes ind icate special meanings.

A symbols binding determines the linkage visibility and behavior.

Figure 1-17: Symbol Binding, ELF32_ST_BIND

Name Value_____________________STB_LOCAL 0

STB_GLOBAL 1

STB_WEAK 2

STB_LOPROC 13

STB_HIPROC 15_____________________

STB_LOCAL Local symbols are not visible outside the object file containing th eir definition. Local

symbols of the same nam e may exist in mu ltiple files withou t interfering w ith each

other.

STB_GLOBAL Global symbols are visible to all object files being combined . One files defin ition of a

global symbol will satisfy another files undefin ed reference to the same global symbol.

STB_WEAK Weak symbo ls resemble global symbols, but their definitions have lower preceden ce.

STB_LOPROC through STB_HIPROC


Global and weak sym bols differ in tw o major ways.

When the link ed itor combines several relocatable object files, it does not allow m ultiple definitions

ofSTB_GLOBAL symbols with the same name. On the other hand , if a defined global symbol

exists, the app earance of a weak sym bol with the same nam e will not cause an error. The link edi-

tor honors the global defin ition and ignores the weak ones. Similarly, if a common sym bol exists

(i.e., a symbol wh ose st_shnd x field holds SHN_COMMON), the appearance of a weak sym bol withthe same name w ill not cause an error. The link editor honors the common definition and ignores

the weak ones.

When the link editor searches archive libraries, it extracts archive mem bers that contain d efinitions

of un defin ed global symbols. The members defin ition may be either a global or a weak symbol.

The link ed itor does notextract archive members to resolve un defined weak sym bols. Unresolved

weak sym bols have a zero value.

In each symbol table, all symbols with STB_LOCAL binding precede the weak and global symbols. As

Sections abov e describes, a symbol table sections sh_info section header mem ber holds the symbol

table index for the fir st non-local sym bol.



25/60


A sym bols type p rovides a general classification for the associated entity.

Figure 1-18: Symbol Types, ELF32_ST_TYPE

Name Value______________________STT_NOTYPE 0

STT_OBJECT 1

STT_FUNC 2

STT_SECTION 3

STT_FILE 4

STT_LOPROC 13

STT_HIPROC 15______________________

STT_NOTYPE The symbols type is not specified.

STT_OBJECT The symbol is associated with a data object, such as a va riable, an ar ray, etc.

STT_FUNC The symbol is associated w ith a function or other executable code.

STT_SECTION The symbol is associated w ith a section. Symbol table entries of this type exist pri-

marily for relocation and normally have STB_LOCAL binding.

STT_FILE Conven tionally, the sym bols nam e gives the nam e of the source file associated w ith the

object file. A file symbol has STB_LOCAL bind ing, its section ind ex is SHN_ABS , and it

precedes the other STB_LOCAL symbols for the file, if it is present.

STT_LOPROC through STT_HIPROC


Function symbols (those with type STT_FUNC) in sha red object files have sp ecial significance. When

anoth er object file references a function from a shared object, the link ed itor autom atically creates a pro-

cedure linkage table entry for the referenced sym bol. Shared object symbols with types other than

STT_FUNC will not be referenced automatically through the procedure linkage table.

If a symbols value r efers to a specific location with in a section, its section ind ex mem ber, st_shndx ,

holds an index into the section head er table. As the section moves du ring relocation, the symbols value

changes as w ell, and references to the symbol continu e to point to the sam e location in th e pr ogram .

Some special section ind ex values give other sem antics.

SHN_ABS The symbol has an absolute value that w ill not change because of relocation.

SHN_COMMON The symbol labels a common block that has not yet been allocated. The symbols value

gives alignmen t constraints, similar to a sections sh_addralign mem ber. That is, the

link editor w ill allocate the storage for the symbol at an add ress that is a mu ltiple of

st_value . The symbols size tells how man y bytes are required.

SHN_UNDEF This section table index means the symbo l is un defin ed. When the link editor combines

this object file with anoth er that d efines the ind icated symbol, this files references to the

symbol w ill be linked to the actual defin ition.



26/60


As men tioned abov e, the symbol table entry for index 0 (STN_UNDEF) is reserved; it holds the following.

Figure 1-19: Symbol Table Entry: Index 0

Nam e Value Note_______________________________________________st_name 0 No name

st_value 0 Zero value

st_size 0 No size

st_info 0 No typ e, local bind ing

st_other 0

st_shndx SHN_UNDEF No section_______________________________________________

Symbol Values

Symbol table entries for d ifferent object file types have slightly d ifferent interp retations for the

st_value member.

In relocatable files, st_value holds alignm ent constraints for a symbol whose section ind ex is

SHN_COMMON .

In relocatable files, st_value holds a section offset for a defin ed sym bol. That is, st_value is an

offset from the beginn ing of the section that st_shndx identifies.

In executab le and shared object files, st_value holds a virtua l addr ess. To make these files sym-

bols more u seful for the d ynam ic linker, the section offset (file interpretation) gives way to a v irtual

address (memory interpretation) for which the section number is irrelevant.

Althou gh the symbol table values have similar m eanings for different object files, the data allow efficientaccess by the app ropriate programs.



27/60

Relocation

Relocation is the p rocess of connecting symbolic references with sym bolic defin itions. For example, when

a prog ram calls a fun ction, the associated call instru ction must tran sfer control to the proper d estination

addr ess at execution. In other word s, relocatable files mu st have informa tion that describes how to

mod ify their section contents, thus allowing executable and shared ob ject files to hold the right informa-

tion for a processs program image. Relocation entries are these data.

Figure 1-20: Relocation Entries

typedef struct {

Elf32_Addr r_offset;

Elf32_Word r_info;

} Elf32_Rel;

typedef struct {

Elf32_Addr r_offset;

Elf32_Word r_info;

Elf32_Sword r_addend;

} Elf32_Rela;

r_offset This member gives the location at wh ich to apply the relocation action. For a relocatable

file, the value is the byte offset from the beginn ing of the section to th e storage unit affected

by the relocation. For an executab le file or a shared object, the value is the virtua l add ress of

the storage u nit affected by the relocation.

r_info This member gives both the sym bol table index with respect to which the relocation mu st be

mad e, and the type of relocation to app ly. For examp le, a call instru ctions relocation entry

wou ld hold th e symbol table ind ex of the function being called. If the index is STN_UNDEF ,

the und efined symbol ind ex, the relocation u ses 0 as the symbol valu e. Relocation types

are pr ocessor-specific. When th e text refers to a relocation entr ys relocation typ e or symboltable ind ex, it means the resu lt of app lying ELF32_R_TYPE or ELF32_R_SYM , resp ectively,

to the en trys r_info member.

#define ELF32_R_SYM(i) ((i)>>8)

#define ELF32_R_TYPE(i) ((unsigned char)(i))

#define ELF32_R_INFO(s,t) (((s)


28/60


A relocation section references two other sections: a symbol table and a section to m odify. The section

headers sh_info an d sh_link members, described in Sections above, specify these relationships.

Relocation entries for d ifferent object files have slightly different inter pretations for the r_offset

member.

In relocatable files, r_offset hold s a section offset. That is, the relocation section itself describeshow to mod ify anoth er section in the file; relocation offsets designate a storage u nit with in the

second section.

In executab le and shared object files, r_offset holds a virtua l addr ess. To make these files relo-

cation entries more u seful for the d ynam ic linker, the section offset (file interpr etation) gives way to

a virtual ad dress (memory interpretation).

Although th e interpretation ofr_offset changes for d ifferent object files to allow efficient access by the

relevant programs, the relocation types meanings stay the same.

Relocation Types

Relocation entries describe how to alter the following instruction and da ta fields (bit numbers ap pear in

the lower box corners).

Figure 1-21: Relocatable Fields

word3231 0

word32 This specifies a 32-bit field occupying 4 bytes with arbitrary byte alignmen t. These values use

the same byte ord er as other wor d values in the 32-bit Intel Architecture.

013

31

022

031

040

0

0x01020304

Calculations below assum e the actions are transforming a relocatable file into either an executable or a

shared object file. Conceptu ally, the link editor merges one or more relocatable files to form th e output.

It first decides how to combine and locate the inp ut files, then up dates the symbol values, and finally p er-

forms the relocation. Relocations app lied to executable or shared object files are similar and accomp lish

the same result. Descriptions below u se the following notation.

A This means th e add end used to compute th e value of the relocatable field.B This means the base add ress at which a shared object has been loaded into m emory d uring

execution. Generally, a shared object file is built with a 0 base virtual ad dr ess, but th e execu-

tion addr ess will be different.



29/60


G This means th e offset into the global offset table at wh ich the addr ess of the relocation entr ys

symbol w ill reside d ur ing execution. See Global Offset Table in Part 2 for more inform a-

tion.

GOT This mean s the ad dress of the global offset table. See Global Offset Table in Part 2 for more

information.

L This means the p lace (section offset or add ress) of the p rocedu re linkage table entry for a sym-

bol. A procedu re linkage table entry red irects a fun ction call to the proper destination. The

link editor builds the initial procedure linkage table, and the dynamic linker modifies the

entries du ring execution. See Procedu re Linkage Table in Part 2 for mor e information.

P This means the p lace (section offset or add ress) of the storage u nit being relocated (comp uted

using r_offset).

S This means the value of the symbol wh ose index resides in the relocation entry.

A r elocation en trys r_offset value d esignates the offset or virtual add ress of the first byte of the

affected storage un it. The relocation type specifies which bits to chan ge and how to calculate their values.

The SYSTEM V architectu re u ses only Elf32_Rel relocation entr ies, the field to be relocated holds theadd end. In all cases, the addend and th e compu ted result use the same byte order.

Figure 1-22: Relocation Types

Name Value Field Calculation___________________________________________________R_386_NONE 0 none none

R_386_32 1 word32 S + A

R_386_PC32 2 word32 S + A - P

R_386_GOT32 3 word32 G + A - P

R_386_PLT32 4 word32 L + A - P

R_386_COPY 5 none none

R_386_GLOB_DAT 6 word32 S

R_386_JMP_SLOT 7 word32 SR_386_RELATIVE 8 word32 B + A

R_386_GOTOFF 9 word32 S + A - GOT

R_386_GOTPC 10 word32 GOT + A - P___________________________________________________

Some relocation types have seman tics beyond simple calculation.

R_386_GOT32 This relocation typ e compu tes the d istance from the base of the global offset

table to the symbols global offset table entry. It add itionally instructs the link

editor to bu ild a global offset table.

R_386_PLT32 This relocation type compu tes the add ress of the symbols procedu re linkagetable entry an d add itionally instructs the link ed itor to build a p rocedu re linkage

table.

R_386_COPY The link ed itor creates this relocation typ e for dynamic linking. Its offset

mem ber refers to a location in a writable segment. The symbol table index

specifies a symbol that shou ld exist both in the curren t object file and in a shared

object. During execution, the dynam ic linker copies data associated with the

shared objects symbo l to the location specified by the offset.



30/60


R_386_GLOB_DAT This relocation typ e is used to set a global offset table entry to th e addr ess of the

specified symbol. The special relocation type allows one to determ ine the

correspond ence between sym bols and global offset table entries.

R_3862_JMP_SLOT The link ed itor creates this relocation type for dynamic linking. Its offset

mem ber gives the location of a procedu re linkage table entry. The dynam iclinker mod ifies the procedu re linkage table entry to tran sfer control to the desig-

nated symbols add ress [see Procedu re Linkage Table in Part 2].

R_386_RELATIVE The link ed itor creates this relocation type for dynamic linking. Its offset

mem ber gives a location within a shared object that contains a value rep resent-

ing a relative add ress. The dynam ic linker compu tes the corresponding virtual

add ress by adding the virtual add ress at wh ich the shared object was loaded to

the relative add ress. Relocation entries for this type must specify 0 for the sym-

bol table index.

R_386_GOTOFF This relocation type compu tes the difference between a sym bols value and the

addr ess of the global offset table. It add itionally instructs the link editor to build

the global offset table.

R_386_GOTPC This relocation typ e resembles R_386_PC32 , except it uses the addr ess of the

global offset table in its calculation. The symbol referenced in th is relocation

normally is_GLOBAL_OFFSET_TABLE_ , which additionally instructs the link

editor to build th e global offset table.



31/60

2 PROGRAM LOADING AND DYNAMIC LINKING

Introduction 2-1

Program Header 2-2Base Address 2-4

Note Section 2-4

Program Loading 2-7

Dynamic Linking 2-10Program Interpreter 2-10Dynamic Linker 2-10

Dynamic Section 2-11

Shared Object Dependencies 2-15

Global Offset Table 2-16

Procedure Linkage Table 2-17

Hash Table 2-19

Initialization and Termination Functions 2-20



32/60

Introduction

Part 2 describes the object file informa tion and system actions that create runn ing progr ams. Some infor-

mation here ap plies to all systems; other information is processor-specific.

Executable and sha red object files statically represent pr ogram s. To execute such program s, the system

uses the files to create dynam ic pr ogram r epresenta tions, or process images. A process image has seg-

men ts that hold its text, da ta, stack, and so on. The major sections in this part discuss the following.

Program header. This section comp lements Par t 1, describing object file structures that relate d irectly

to program execution. The primary d ata structure, a program h eader table, locates segment images

within the file and contains other information necessary to create the memory image for the pro-

gram.

Program loading. Given an object file, the system m ust load it into mem ory for the program to run .

Dynamic linking. After the system loads the p rogram , it mu st complete the process image by resolv-

ing sym bolic references among th e object files that comp ose the p rocess.

NOTE

There are naming conventions for ELF constants that have specified processor ranges. Names such asDT_, PT_, for processor-specific extensions, incorporate the name of the processor:

DT_M32_SPECIAL, for example. Preexisting processor extensions not using this convention will besupported.

Pre-existing Extensions_____________________

DT_JMP_REL



33/60

Program Header

An executable or shared object files progr am h eader table is an array of structures, each describing a seg-

men t or other informa tion the system needs to prepa re the program for execution. An object file segment

contains one or more sections , as Segmen t Contents describes below. Program head ers are meaningful

only for executable and sh ared ob ject files. A file specifies its own pr ogram head er size with the ELF

headers e_phentsize an d e_phnum members [see ELF Head er in Part 1].

Figure 2-1: Program Header

typedef struct {

Elf32_Word p_type;

Elf32_Off p_offset;

Elf32_Addr p_vaddr;

Elf32_Addr p_paddr;

Elf32_Word p_filesz;

Elf32_Word p_memsz;

Elf32_Word p_flags;

Elf32_Word p_align;

} Elf32_Phdr;

p_type This member tells what kind of segment this array element d escribes or how to interpret

the array elements information. Type values and their meanings app ear below.

p_offset This member gives the offset from th e beginning of the file at wh ich the first byte of the

segment resides.

p_vaddr This member gives the virtual add ress at wh ich th e first byte of the segment resides in

memory.

p_paddr On system s for wh ich physical addr essing is relevant, this member is reserved for the

segmen ts physical add ress. Because System V ignores physical add ressing for applica-tion programs, this member has unspecified contents for executable files and shared

objects.

p_filesz This member gives the n um ber of bytes in the file image of the segmen t; it may be zero.

p_memsz This member gives the num ber of bytes in the memory image of the segment; it may be

zero.

p_flags This member gives flags relevant to the segment. Defined flag values ap pear below.

p_align As Program Loading later in this par t describes, loadable process segments m ust h ave

congruent values for p_vaddr and p_offset , modu lo the page size. This member

gives the value to w hich the segments are aligned in memory an d in the file. Values 0

and 1 mean no alignment is required. Otherwise, p_align shou ld be a positive, integral

pow er of 2, and p_vaddr should equal p_offset , modulo p_align .

Some entries describe process segments; others give supplementary information and do not contribute to

the process image. Segmen t entries may ap pear in any ord er, except as explicitly noted below. Defined

type values follow; other values are reserved for futu re use.



34/60


Figure 2-2: Segment Types, p_type

Name Value___________________________PT_NULL 0

PT_LOAD 1PT_DYNAMIC 2

PT_INTERP 3

PT_NOTE 4

PT_SHLIB 5

PT_PHDR 6

PT_LOPROC 0x70000000

PT_HIPROC 0x7fffffff___________________________

PT_NULL The array element is unu sed; other mem bers values are und efined. This type lets the

program header table have ignored entries.

PT_LOAD The array element specifies a loadable segment, described by p_filesz an d p_memsz .

The bytes from the file are map ped to the beginning of the mem ory segment. If the

segmen ts mem ory size (p_memsz) is larger th an th e file size (p_filesz), the extra

bytes are defined to hold the value 0 and to follow the segmen ts initialized area. The file

size may n ot be larger than the memory size. Loadable segment entries in the p rogram

header table appear in ascending ord er, sorted on the p_vaddr member.

PT_DYNAMIC The array element sp ecifies dynam ic linking inform ation. See Dynamic Section below

for more information.

PT_INTERP The array element specifies the location and size of a nu ll-terminated path nam e to

invoke as an interpreter. This segmen t type is mean ingful only for executab le files

(though it may occur for shared objects); it may no t occur m ore than once in a file. If it is

presen t, it mu st precede any load able segment entry . See Program Interpr eter belowfor further information.

PT_NOTE The array elemen t specifies the location and size of auxiliary information. See Note Sec-

tion below for details.

PT_SHLIB This segment type is reserved bu t has un specified semantics. Programs that contain an

array elemen t of this type d o not conform to the ABI.

PT_PHDR The array element, if pr esent, specifies the location and size of the pr ogram h eader tab le

itself, both in the file and in th e memory image of the program . This segment type m ay

not occur m ore than once in a file. Moreover, it may occur only if the prog ram h eader

table is part of the memory image of the prog ram . If it is present, it mu st precede any

loadable segmen t entry. See Program Interpr eter below for further inform ation.

PT_LOPROC through PT_HIPROC




35/60


36/60


namesz an d name

The first namesz bytes in name contain a null-terminated character representation of the

entrys owner or originator. There is no forma l mechan ism for avoiding nam e conflicts. By

convention, vend ors use their own n ame, such as XYZ Com pu ter Comp any, as the

identifier. If no nam e is pr esent, namesz contains 0. Pad ding is presen t, if necessary, to

ensu re 4-byte alignmen t for the descriptor. Such padd ing is not includ ed in namesz .

descsz an d desc

The first descsz bytes in desc hold th e note descriptor. The ABI places no constraints on a

descriptors contents. If no descriptor is present, descsz contains 0. Padding is presen t, if

necessary, to ensu re 4-byte alignm ent for the next note entry. Such pad ding is not includ ed

in descsz .

type This word gives the interp retation of the descriptor. Each originator controls its own typ es;

mu ltiple interpr etations of a single type value may exist. Thus, a program m ust recognize

both the nam e and the type to un derstand a descriptor. Types currently mu st be non-

negative. The ABI does not define wh at descriptors mean.

To illustrate, the following note segmen t holds tw o entries.

Figure 2-4: Example Note Segment

+0 +1 +2 +3______________________namesz 7______________________descsz 0 No d escriptor______________________type 1______________________name X Y Z______________________

C

o

\0

pad____________________________________________namesz 7______________________descsz 8______________________type 3______________________name X Y Z______________________

C

o

\0

pad______________________desc word 0______________________

word 1______________________

NOTE

The system reserves note information with no name (namesz= =0) and with a zero-length name(name[0]= =\0) but currently defines no types. All other names must have at least one non-nullcharacter.

Tool Interface Standards (TIS) Portable Formats Spe cification , Version 1.1 2-5


37/60


NOTE

Note information is optional. The presence of note information does not affect a programs ABI confor-mance, provided the information does not affect the programs execution behavior. Otherwise, the pro-gram does not conform to the ABI and has undefined behavior.



38/60


39/60


The last text page holds a copy of the beginning of data .

The first data page h as a copy of the end of text.

The last data page m ay contain file information n ot relevant to th e run ning p rocess.

Logically, the system enforces the memory p ermissions as if each segment w ere comp lete and separ ate;segmen ts addr esses are adjusted to ensur e each logical page in the addr ess space has a single set of per-

missions. In the examp le above, the region of the file holding the end of text and the beginning of data

will be mapp ed tw ice: at one virtual ad dress for text and at a d ifferent virtual add ress for d ata.

The end of the data segment requ ires special hand ling for un initialized data, w hich the system d efines to

begin with zero values. Thus if a files last da ta page includ es informa tion not in the logical memory

page, the extraneou s data mu st be set to zero, not the unknow n contents of the executab le file. Impu ri-

ties in the other th ree pages ar e not logically part of the pr ocess image; whether th e system expu nges

them is unsp ecified. The memor y image for this program follows, assum ing 4 KB (0x1000) pages.

Figure 2-7: Process Image Segments

Virtual Add ress Contents Segment

____________________0x8048000 Header padding0x100 bytes____________________

0x8048100

Text

Text segmen t

. . .

0x2be00 bytes____________________0x8073f00 Data padding

0x100 bytes

____________________

____________________0x8074000 Text padding

0xf00 bytes____________________0x8074f00 DataData segment

. . .

0x4e00 bytes____________________0x8079d00 Uninitialized data

0x1024 zero bytes____________________0x807ad24 Page padding

0x2dc zero bytes____________________

One asp ect of segmen t loading d iffers between executable files and shared objects. Executable file seg-

men ts typically contain absolute code. To let the process execute correctly, the segmen ts mu st reside at

the virtual add resses used to bu ild th e executable file. Thus the system uses the p_vaddr values

un changed as virtual addresses.



40/60


On the other han d, shared object segments typically contain position-indep end ent code. This lets a

segments virtual address change from one process to another, without invalidating execution behavior.

Though the system chooses virtual addresses for individual processes, it maintains the segments relative

positions. Because position-independ ent code uses relative add ressing between segments, the difference

between virtual add resses in memory mu st match the d ifference between virtual ad dresses in the file.

The following table shows p ossible shared object virtual add ress assignmen ts for several processes, illus-

trating constant relative positioning. The table also illustra tes the base addr ess comp utations.

Figure 2-8: Example Shared Object Segment Addresses

Sourc Text Data Base Ad dr ess______________________________________________________File 0x200 0x2a400 0x0

Process 1 0x80000200 0x8002a400 0x80000000

Process 2 0x80081200 0x800ab400 0x80081000

Process 3 0x900c0200 0x900ea400 0x900c0000

Process 4 0x900c6200 0x900f0400 0x900c6000______________________________________________________



41/60

Dynamic Linking

Program Interpreter

An executable file may have one PT_INTERP program header element. During exec(BA_OS), the sys-tem retrieves a path nam e from the PT_INTERP segment an d creates the initial process image from th e

interpr eter files segmen ts. That is, instead of using th e original executable files segment images, the sys-tem comp oses a mem ory image for the interp reter. It then is the interpr eters responsibility to receive

control from the system an d provide an environment for the app lication p rogram.

The interpr eter receives control in one of two w ays. First, it may receive a file descriptor to read the exe-

cutable file, positioned at the beginning. It can u se this file descriptor to read and / or map the executable

files segments into memory. Second, dep end ing on the executable file form at, the system m ay load the

executab le file into mem ory instead of giving the interp reter an open file descriptor. With the possible

exception o f the file descriptor, the interp reters initial pr ocess state ma tches wh at the executable file

wou ld have received. The interpreter itself may n ot require a second interpreter. An interpreter may be

either a shar ed object or an executable file.

A shared object (the normal case) is loaded as position-ind epend ent, with ad dresses that may vary

from one p rocess to another; the system creates its segments in the d ynam ic segmen t area used by

mmap(KE_OS) and related services. Consequ ently, a shared object interp reter typ ically will notconflict with the or iginal executable files original segment add resses.

An executable file is loaded at fixed ad dr esses; the system creates its segments u sing the virtual

addr esses from the program h eader table. Consequ ently, an executab le file interpr eters virtua l

addr esses may collide with the first executable file; the interp reter is responsible for resolving

conflicts.

Dynamic Linker

When bu ilding an executable file that uses dyn amic linking, the link editor add s a p rogram h eader ele-

ment of type PT_INTERP to an executable file, telling the system to invoke th e dyn amic linker as the pro-

gram interpreter.

NOTE

The locations of the system provided dynamic linkers are processorspecific.

Exec(BA_OS) and the dynam ic linker cooperate to create the pr ocess image for the prog ram , whichentails the following actions:

Ad ding th e executable files memor y segments to the p rocess image;

Add ing shared object mem ory segments to the p rocess image;

Performing r elocations for the executable file and its shared objects;

Closing the file descriptor that was u sed to read th e executable file, if one was given to the dynam ic

linker;

Transferring control to the program, mak ing it look as if the pr ogram had received contro l directly

from exec(BA_OS).



42/60


The link ed itor also constru cts various data that assist the dynam ic linker for executable and shared object

files. As shown above in Program Head er, these data reside in loadable segments, making them avail-

able du ring execution. (Once again, recall the exact segmen t contents are processor-specific. See the pro-

cessor supplement for complete information.)

A .dynamic section with type SHT_DYNAMIC holds various data. The structure residing at thebeginning of the section holds the addresses of other dynamic linking information.

The .hash section with type SHT_HASH holds a symbol hash table.

The .got an d .plt sections with type SHT_PROGBITS hold two separa te tables: the global offset

table and the procedure linkage table. Sections below explain how the dyn amic linker uses and

changes th e tables to create memory images for object files.

Because every ABI-conforming p rogram imports the basic system services from a shared object library,

the dynam ic linker participates in every ABI-conforming p rogram execution.

As Program Loading explains in the processor supp lement, shared objects may occup y virtual mem ory

add resses that are d ifferent from the add resses recorded in the files program header table. The dynam ic

linker relocates the memory image, updating absolute addresses before the application gains control.

Although th e absolute ad dress values w ould be correct if the library w ere loaded at th e add resses

specified in the pr ogram h eader table, this norm ally is not the case.

If the p rocess environ men t [see exec(BA_OS)] contains a variable nam ed LD_BIND_NOW with a non-nullvalue, the dyn amic linker processes all relocation before transferring control to the program . For exam-

ple, all the following environm ent entries wou ld specify this behavior.

LD_BIND_NOW=1

LD_BIND_NOW=on

LD_BIND_NOW=off

Otherwise, LD_BIND_NOW either does not occur in the environment or has a n ull value. The dynamic

linker is permitted to evaluate procedure linkage table entries lazily, thus avoiding symbol resolution and

relocation overh ead for functions that ar e not called. See Procedu re Linkage Table in this part for mor einformation.

Dynamic Section

If an object file participates in d ynam ic linking, its prog ram h eader table will have an element of type

PT_DYNAMIC . This segm ent contain s the .dynamic section. A special symbol,_DYNAMIC , labels the

section, which contains an array of the following stru ctures.

Tool Interface Standards (TIS) Portable Formats Specifi cation, Version 1.1 2-11


43/60


Figure 2-9: Dynamic Structure

typedef struct {

Elf32_Sword d_tag;

union {

Elf32_Word d_val;

Elf32_Addr d_ptr;

} d_un;

} Elf32_Dyn;

extern Elf32_Dyn _DYNAMIC[];

For each object with th is type, d_tag controls the interpretation ofd_un.

d_val These Elf32_Word objects represent integer values with various interpretations.

d_ptr These Elf32_Addr objects represent program v irtual addresses. As mentioned p reviously,

a files virtual add resses might not match the m emory virtual add resses du ring execution.

When interpreting ad dresses contained in the dyn amic structure, the dyn amic linker com-

pu tes actual add resses, based on the original file value and the m emory base address. For

consistency, files do notcontain relocation entr ies to correct add resses in the d ynam ic

structure.

The following table sum mar izes the tag requiremen ts for executab le and shar ed object files. If a tag is

mar ked man da tory, then th e dyn amic linking arr ay for an ABI-conforming file must have an en try of

that typ e. Likewise, optional mean s an entry for the tag may app ear but is not required.

Figure 2-10: Dynamic Array Tags, d_tag

Name Value d_un Executable Shared Object_______________________________________________________________________DT_NULL 0 ignored mandatory mandatory

DT_NEEDED 1 d_val optional optional

DT_PLTRELSZ 2 d_val optional optional

DT_PLTGOT 3 d_ptr optional optional

DT_HASH 4 d_ptr mandatory mandatory

DT_STRTAB 5 d_ptr mandatory mandatory

DT_SYMTAB 6 d_ptr mandatory mandatory

DT_RELA 7 d_ptr mandatory optional

DT_RELASZ 8 d_val mandatory optional

DT_RELAENT 9 d_val mandatory optional

DT_STRSZ 10 d_val mandatory mandatory

DT_SYMENT 11 d_val mandatory mandatoryDT_INIT 12 d_ptr optional optional

DT_FINI 13 d_ptr optional optional

DT_SONAME 14 d_val ignored optional

DT_RPATH 15 d_val optional ignored

DT_SYMBOLIC 16 ignored ignored optional



44/60


Figure 2-10: Dynamic Array Tags, d_tag (continued )

Name Value d_un Executable Shared Object_______________________________________________________________________DT_REL 17 d_ptr mandatory optional

DT_RELSZ 18 d_val mandatory optionalDT_RELENT 19 d_val mandatory optional

DT_PLTREL 20 d_val optional optional

DT_DEBUG 21 d_ptr optional ignored

DT_TEXTREL 22 ignored optional optional

DT_JMPREL 23 d_ptr optional optional

DT_LOPROC 0x70000000 unspecified unspecified unspecified

DT_HIPROC 0x7fffffff unspecified unspecified unspecified_______________________________________________________________________

DT_NULL An entry with a DT_NULL tag marks the end of the_DYNAMIC array.

DT_NEEDED This elemen t holds the string table offset of a nu ll-termina ted string, giving the nam e ofa needed library. The offset is an index into the table recorded in the DT_STRTAB

entry. See Shared Object Dependen cies for more information about th ese names.

The dynamic array may contain mu ltiple entries with this type. These entries relative

order is significant, though their relation to entries of other types is not.

DT_PLTRELSZ This elemen t holds the total size, in by tes, of the relocation entries associated with the

procedur e linkage table. If an entry of type DT_JMPREL is present, a DT_PLTRELSZ

mu st accompany it.

DT_PLTGOT This element holds an ad dress associated w ith the procedure linkage table and / or the

global offset table. See this section in the pr ocessor supp lement for details.

DT_HASH This element holds th e addr ess of the symbol hash table, described in Hash Table.

This hash table refers to the symbol table referenced by th e DT_SYMTAB element.

DT_STRTAB This element hold s the add ress of the string table, described in Part 1. Symbol names,

library nam es, and other strings reside in this table.

DT_SYMTAB This element h olds the ad dr ess of the sym bol table, described in Part 1, with

Elf32_Sym ent ries for the 32-bit class of files.

DT_RELA This elemen t holds the ad dr ess of a relocation table, described in Part 1. Entries in the

table have explicit addends, such as Elf32_Rela for the 32-bit file class. An ob ject file

may h ave mu ltiple relocation sections. When bu ilding the relocation table for an exe-

cutable or shar ed ob ject file, the link editor catenates th ose sections to form a sing le

table. Althou gh the sections remain ind ependen t in the object file, the dynam ic linker

sees a single table. When th e dyn amic linker creates the process image for an execut-

able file or add s a shared object to the process image, it reads the relocation table andperform s the associated actions. If this element is present, the dynamic structure mu st

also have DT_RELASZ an d DT_RELAENT elements. When relocation is man da tory

for a file, either DT_RELA or DT_REL may occur (both are p ermitted but n ot required).

DT_RELASZ This elemen t holds the total size, in bytes, of the DT_RELA relocation table.



45/60


DT_RELAENT This element holds th e size, in bytes, of the DT_RELA relocation entry.

DT_STRSZ This elemen t holds the size, in bytes, of the string table.

DT_SYMENT This elemen t holds the size, in bytes, of a symbol table entry .

DT_INIT This elemen t hold s the ad dr ess of the initialization function, d iscussed in Initializationand Termination Fun ctions below.

DT_FINI This element holds th e add ress of the termination function, discussed in Initialization

and Termination Fun ctions below.

DT_SONAME This elemen t holds the string table offset of a nu ll-termina ted string, giving the nam e of

the shared object. The offset is an index into the table recorded in the DT_STRTAB

entry. See Shared Ob ject Depend encies below for mor e information abou t these

names.

DT_RPATH This elemen t holds the string table offset of a nu ll-termina ted search library search path

string, d iscussed in Shared O bject Depend encies. The offset is an ind ex into the tab le

recorded in the DT_STRTAB entry.

DT_SYMBOLIC This element s presence in a shared object library alters the d ynam ic linkers symbol

resolution algorithm for references within the library. Instead of starting a symbol

search with th e executab le file, the dyn amic linker starts from th e shared object itself. If

the shar ed object fails to supp ly the referenced symbol, the dynam ic linker then

searches the executab le file and other sha red ob jects as usu al.

DT_REL This element is similar to DT_RELA , except its table has imp licit add end s, such as

Elf32_Rel for the 32-bit file class. If t

Date post:	30-May-2018
Category:	Documents
Upload:	raja-mustafa
View:	223 times
Download:	0 times

Executable and Linkable Format (ELF)

Documents