ELF Format

8/14/2019 ELF Format

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 Specification, 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, V ersion 1.1 iii


5/60

Preface

ELF: Executable and Linking Format

The Executable and Linking Forma t was originally developed and pu blished by UNIX System Labora-

tories (USL) as part of the Ap plication Binary Interface (ABI). The Tool Interface Standard s comm ittee

(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 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 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:

Part 1, Object Files describes the ELF object file form at for the th ree main types of object files.

Part 2, Program Loading and Dynamic Linking describes the object file information and system

actions that create runn ing program s.

Part 3, C Library lists the sym bols 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

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


7/60

Introduction

Par t 1 describes th e iABI object file form at, called ELF (Executable and Linking Format). There are three

main types of object files.

A relocatable file holds code an d d ata suitable for linking w ith other object files to create an execut-

able or a shar ed object file.

An executable file holds a program suitable for execution; the file specifies how exec(BA_OS) createsa program s 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 pr ocess it with other relocatable and shared object files to create anoth er objectfile. Second, the dyn amic 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 rep resentations 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 material, Part 1 focuses on the file format and how it pertains to building pro-

gram s. Part 2 also describes parts of the object file, concentrating on th e information necessary to executea program.

File Format

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

gram ). For convenience and efficiency, the object file form at pr ovides parallel views of a files contents,

reflecting th e differing n eeds of these activities. Figure 1-1 show s an object files organization.

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 beginning and holds a road map describing the files organization. Sec-

tions hold the bu lk of object file informa tion for the linking view: instru ctions, 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-1


8/60


A program header table, if present, tells the system how to create a process image. Files used to bu ild a pro-

cess image (execute a p rogram ) must hav e a program head er table; relocatable files do not need one. A

section header tablecontains information describing the files sections. Every section has an entry in the

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

ing mu st have a section header 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 w ith a m achine-ind epend ent format, making it p ossible to identify

object files and interpret their contents in a comm on 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 th e object file format d efines follow t he natural size and alignment guidelines

for the relevant class. If necessary, data structures contain explicit padding 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 within the file.

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

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


9/60

ELF Header

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

object file format changes, a program may encounter control structures that are larger or smaller than

expected. Program s might therefore ignore extra information. The treatmen t ofmissing informa-

tion depend s on context and w ill 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 provide machine-independ ent data

with wh ich to decode and interpret the files contents. Comp lete descriptions app ear

below, in ELF Identification.

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 conten ts are unsp ecified, type ET_CORE is reserved to mark the

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

object file types as necessary.



10/60


e_machine This members value specifies the required architecture for an individual 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 nam es use the machine nam e to distingu ish them. For examp le,

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 mem ber 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 nu mber.

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 p oint, this mem ber holds zero.

e_phoff This member holds the program header tables file offset in bytes. If the file has no

program header table, this member h olds zero.

e_shoff This member holds the section header tables file offset in bytes. If the file has no sec-

tion header table, this member h olds zero.

e_flags This member hold s 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 hold s the ELF headers size in bytes.

e_phentsize This member hold s the size in bytes of one entry in the files program header 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 pro-

gram head er table, e_phnum holds the value zero.

e_shentsize This member holds a section headers 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 head er 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 name string table. If the file has no section nam e string table, this mem ber holds

the value SHN_UNDEF . See Sections an d String Table below for more informa-

tion.

ELF Identification

As men tioned above, ELF provides an object file framew ork to sup port m ultiple processors, multiple data

encodings, and mu ltiple classes of machines. To supp ort this object file family, the initial bytes of the file

specify how to interpret the file, independ ent of the processor on wh ich the inquiry is made and indepen-

dent of the files remaining contents.

The initial bytes of an ELF head er (and an ob ject file) correspond 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 nu mber, 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] , iden tifies 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 form at is designed to be portable amon g machines of various sizes, without

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

machines with files and virtu al add ress spaces up to 4 gigabytes; it uses the basic types

defined above.

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

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

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

EI_DATA Byte e_ident[EI_DATA] specifies the data encod ing of the processor-specific data in

the object file. The following encodings are cur rently 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 and

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; programs 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 encoding specifies how to interpr et the basic objects in a file. As described above, class

ELFCLASS32 files use objects that occup y 1, 2, and 4 bytes. Und er the defined encodings, objects arerepresented as shown below. Byte num bers appear in the up per left corners.

Encoding ELFDATA2LSB specifies 2s complemen t values, with the least significant byte occup ying 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 complement values, with the m ost 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 head ers e_flags member h olds bit flags associated with the file. The 32-bit Intel Architectur e

defines no flags; so this mem ber contains zero.



14/60

Sections

An object files section h eader 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 ob ject file will not have 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 und efined , missing, irrelevant, or otherw ise meaningless section

reference. For example, a symbol defined relative to section nu mber SHN_UNDEF

is an und efined symbol.

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 ran ge are reserved for processor-specific seman tics.

SHN_ABS This value specifies absolute values for the correspond ing reference. For examp le,

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 comm on sym bols, such as FORTRAN

COMMON or unallocated C external variables.

SHN_HIRESERVE This value specifies the upp er bound of the range of reserved indexes. 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 program header table, and th e

section head er table. Moreover, object files sections satisfy several cond itions.



15/60


Every section in an object file has exactly one section head er describing it. Section headers m ay

exist that d o not have a section.

Each section occup ies one contiguous (possibly empty) sequence of bytes within a file.

Sections in a file may not overlap. No byte in a file resides in m ore than one section.

An object file may have 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 unspecified .

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 specifies the nam e of the section. Its value is an index into the section

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

terminated string.

sh_type This mem ber categorizes the sections conten ts and seman tics. Section types and th eir

descriptions app ear below.

sh_flags Sections su pp ort 1-bit flags that describe miscellaneous attribu tes. 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

add ress at wh ich th e sections first byte should reside. Otherwise, the member con-

tains 0.

sh_offset This members value gives the byte offset from the beginn ing of 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 typ e 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 h eader table index link, wh ose interpretation depend s

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



16/60


sh_info This member holds extra information, whose interpretation d epends on th e 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 hold s 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, modu lo 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 offixed-size entries, such as a symbol 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 hold a table offixed-size entries.

A section headers sh_type member sp ecifies 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 informa tion defined by the program , whose 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 hav e 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 dynam ic 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 details.



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

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

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 relaxed in the future. 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 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 d etails.

SHT_NOBITS A section of this type occup ies no space in the file but otherw ise 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 add end s, such as typ e

Elf32_Rel for the 32-bit class of ob ject files. An object file may have multiple reloca-

tion sections. See Relocation below for deta ils.

SHT_SHLIB This section typ e is reserved bu t has un specified semantics. Programs that contain a

section of this type do not conform to the ABI.

SHT_LOPROC through SHT_HIPROC


SHT_LOUSER This value specifies the lower boun d of the range of indexes reserved for app lication

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 futu re 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 ind ex marks und efined section references. This entry holds 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 headers sh_flags member holds 1-bit flags tha t 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 attribute is on for the section. Otherw ise, the attribute is off or

does not apply. Undefined 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 image 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 seman tics.

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 uninitialized data that contribute to the program s mem ory image. By

definition, the system initializes the data w ith zeros when the p rogram 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 d ata that contribu te to the program s memory image.

.debug This section holds informa tion for symbolic debu gging. The contents are un specified .

.dynamic This section hold s dynamic linking informa tion. The sections 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 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 th e dyn amic 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 termination 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 globa l offset table. See Special Sections in Part 1 and Global

Offset Table in Part 2 for more information.

.hash This section hold s a symbol hash table. See Hash Table in Part 2 for more information.

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

That is, wh en a p rogram starts to ru n, 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 holds the pa th nam e of a program interp reter. If the file has a loadable seg-

men t that includ es the section, the sections attributes will 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 hold s inform ation in the format that Note Section in Part 2 describes.

.plt This section holds the procedu re linkage table. See Special Sections in Part 1 and Pro-

cedure Linkage Table in Part 2 for more information.

.relname and .relaname

These sections h old relocation information , as Relocation below describes. If the file has

a loadab le segmen t that includes relocation, the sections attributes will include 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 segmen t in

the process image. See Program Header in Part 2 for mor e information.

.shstrtab This section holds section names.

.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 sym bol table, as Symbol Table in this section describes. If the file

has a loadable segment that includes the sym bol table, the sections attributes w ill include

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

.text This section holds the text, or executable instru ctions, of a prog ram .

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

tions if their existing mean ings are satisfactory. App lications may use names without the p refix to avoid

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

object file may have more than one section with the same nam e.

Section names reserved for a processor architecture ar e 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 p sect 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-terminated character sequences, common ly 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, wh ich is index zero, is defined to hold a nu ll character. Likewise, a

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

string whose index is zero specifies either no name or a nu ll name, depend ing on the context. An emp tystring table section is per mitted ; its section header s sh_size member wou ld contain zero. Non-zero

indexes are invalid for an emp ty string table.

A section headers 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 information needed to locate and relocate a program s symbolic

definitions and references. A symbol table ind ex is a subscript into this array. Index 0 both designates

the first entry in the table and serves as the und efined sym bol ind ex. The conten ts 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 repr esents 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 examp le, a data objects size is the num ber of

bytes contained in th e object. This member h olds 0 if the sym bol has no size or an

unknown size.

st_info This member 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 d efined meaning.

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

relevant section head er table ind ex. As Figu re 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 v isible outside the object file containing th eir definition. Local

symbols of the same nam e may exist in mu ltiple files without interfering with each

other.

STB_GLOBAL Global symbols are visible to all object files being combined . One files d efinition of a

global symbol w ill satisfy ano ther files undefined reference to the same global symbol.

STB_WEAK Weak symbo ls resemble global symbols, bu t their definitions have lower precedence.

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 mu ltiple definitions

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

exists, the app earance of a weak symbol with the same n ame w ill not cause an error. The link ed i-

tor honors the global definition and ignores the w eak ones. Similarly, if a common symbol exists

(i.e., a symbol wh ose st_shndx field h olds SHN_COMMON), the app earance of a w eak symbol withthe same name w ill not cause an error. The link editor honors the comm on definition and ignores

the weak ones.

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

of und efined global symbols. The members d efinition may be either a global or a weak symbol.

The link ed itor does notextract archive members to resolve undefined w eak symbols. Unresolved

weak sym bols have a zero value.

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

Sections above d escribes, a symbo l table sections sh_info section header mem ber holds the symbol

table index for the first non -local symbol.



25/60


A symbols type p rovides a genera l 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. Sym bol table entries of this type exist pri-

marily for relocation and normally have STB_LOCAL binding.

STT_FILE Conventionally, the symbols nam e gives the name of the source file associated with 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 presen t.

STT_LOPROC through STT_HIPROC


Function symbols (those with type STT_FUNC) in shared 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 sym bols value refers to a specific location w ithin a section, its section ind ex member , st_shndx ,

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

changes as well, and references to the symbol continu e to point to the same location in the program .

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 m any bytes are requ ired.

SHN_UNDEF This section table index means the symbol is un defined. When the link editor combines

this object file with another that defines the ind icated sym bol, this files references to the

symbol w ill be linked to the actual definition.



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 en tries for d ifferent object file types have slightly d ifferent interpretations for the

st_value member.

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

SHN_COMMON .

In r elocatable files, st_value holds a section offset for a d efined symbol. 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 virtual add ress. To make these files sym-

bols more u seful for the d ynam ic linker, the section offset (file interp retation) gives way to a virtual

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 symbolic definitions. For examp le, wh en

a prog ram calls a fun ction, the associated call instru ction m ust tran sfer control to the prop er destination

addr ess at execution. In other words, relocatable files must have information that d escribes how to

mod ify their section contents, thu s allowing executable and sh ared object files to hold th e 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 app ly the relocation action. For a relocatable

file, the value is the byte offset from the beginn ing of the section to the storage u nit affected

by the relocation. For an executable file or a shared ob ject, the value is the virtual 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 entr y

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

the undefined symbol ind ex, the relocation u ses 0 as the symbol value. Relocation typ es

are p rocessor-specific. When th e text refers to a relocation entry s relocation type or symboltable ind ex, it means the resu lt of app lying ELF32_R_TYPE or ELF32_R_SYM , resp ectively,

to the entrys 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 oth er sections: a symbol table and a section to mod ify. The section

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

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

member.

In r elocatable files, r_offset hold s a section offset. That is, the relocation section itself describeshow to mod ify another section in the file; relocation offsets designate a storage u nit w ithin the

second section.

In executab le and shared object files, r_offset holds a virtual add ress. To make these files relo-

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

a virtual ad dress (memory interpretation).

Although th e interpretation ofr_offset changes for d ifferent object files to allow efficient a ccess by th e

relevant programs, the relocation types meanings stay the same.

Relocation Types

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

the lower box corners).

Figure 1-21: Relocatable Fields

word3231 0

word32 This specifies a 32-bit field occup ying 4 bytes with arbitrary byte alignm ent. 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 assu me 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 the outp ut.

It first decides how to combine and locate the input files, then u pd ates the symbol values, and finally per-

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 the ad dend used to comp ute the 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 the 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 entry s

symbol will reside du ring execution. See Global Offset Table in Part 2 for mor e informa-

tion.

GOT This means the ad dr ess 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 pr ocedur e 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 ed itor builds the initial procedure linkage table, and the dyn amic linker m odifies the

entries du ring execution. See Procedu re Linkage Table in Part 2 for more inform ation.

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 ind ex resides in the relocation entry .

A relocation entr ys r_offset value d esignates the offset or virtual add ress of the first byte of the

affected storage unit. The relocation type specifies wh ich bits to chan ge and how to calculate their values.

The SYSTEM V architectu re u ses only Elf32_Rel relocation en tries, the field to be relocated holds theadd end. In all cases, the add end and the comp uted 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 comp utes the add ress of the symbols procedure 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 should exist both in the cur rent object file and in a shared

object. During execution, the dyn amic linker copies da ta associated w ith the

shared objects symbol 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 add ress of the

specified symbol. The special relocation type allows one to determine the

correspond ence between sym bols and global offset table entries.

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

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

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

R_386_RELATIVE The link ed itor creates this relocation typ e 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 this relocation

normally is_GLOBAL_OFFSET_TABLE_ , which additionally instructs the link

editor to bu ild the 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

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


32/60

Introduction

Part 2 d escribes the object file information and system actions that create run ning program s. Some infor-

mation h ere app lies to all systems; other information is processor-specific.

Executable and sh ared object files statically represent progr ams. To execute such p rogram s, the system

uses the files to create dynam ic prog ram rep resentations, 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 d iscuss the following.

Program header. This section comp lements Pa rt 1, describing object file structures that relate directly

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 memory for the program to run.

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

ing sym bolic references among the object files that comp ose the process.

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 header tab le is an array of structures, each describing a seg-

ment or other information the system needs to p repare the p rogram for execution. An object file segment

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

only for executable and sh ared object files. A file specifies its own program header 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 th is array element d escribes or how to interpret

the array elements information. Type values and their meanings appear below.

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

segment resides.

p_vaddr This member gives the virtual ad dress at w hich the first byte of the segment resides in

memory.

p_paddr On system s for wh ich physical add ressing is relevant, this member is reserved for the

segments physical add ress. Because System V ignores physical add ressing for applica-tion programs, this member has u nspecified conten ts for executable files and shared

objects.

p_filesz This member gives the num ber of bytes in th e 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 appear below.

p_align As Program Loading later in this par t describes, loadable pr ocess segmen ts must have

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 th e 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 un used; other members values are un defined . 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 th e file are map ped to the beginning of the memory segment. If the

segments memory size (p_memsz) is larger than th e file size (p_filesz), the extra

bytes are defined to h old the value 0 and to follow the segments initialized area. The file

size may n ot be larger than the mem ory 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 specifies dynam ic linking informa tion. See Dynamic Section below

for more information.

PT_INTERP The array element specifies the location and size of a nu ll-termina ted p ath name 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 not occur m ore than once in a file. If it is

presen t, it mu st precede any loadable segmen t entry. See Program Interpreter belowfor further information.

PT_NOTE The array element specifies the location and size of auxiliary informa tion. See Note Sec-

tion below for details.

PT_SHLIB This segment type is reserved but has un specified semantics. Program s that contain an

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

PT_PHDR The array elemen t, if pr esent, specifies the location and size of the program header table

itself, both in the file and in the memory image of the program. This segment type may

not occur m ore than once in a file. Moreover, it may occur only if the progr am head er

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

loadable segmen t entry. See Program Interpreter below for further information.

PT_LOPROC through PT_HIPROC




35/60


NOTE

Unless specifically required elsewhere, all program header segment types are optional. That is, a filesprogram header table may contain only those elements relevant to its contents.

Base Address

Executab le and shared object files have a base address, which is the lowest virtua l add ress associated with

the memory image of the program s object file. One use of the base add ress is to relocate the mem ory

image of the program du ring dynam ic linking.

An executable or sha red object files base add ress is calculated d ur ing execution from th ree values: the

memory load ad dress, the maximum page size, and the lowest virtual add ress of a program s loadable

segment. As Program Loading

in this chapter d escribes, the virtual addr esses in the program headers m ight not represent the actual vir-

tual add resses of the program s memory image. To compu te the base add ress, one determines the

memory add ress associated w ith the lowest p_vaddr value for a PT_LOAD segment. One then obtainsthe base add ress by truncating the m emory ad dress to the nearest multiple of the maximum page size.

Depend ing on the kind offile being loaded into memory, the memory ad dress might or might not m atch

the p_vaddr values.

As Sections in Part 1 d escribes, the .bss section has the type SHT_NOBITS . Although it occup ies no

space in the file, it contribu tes to the segmen ts memory image. Norm ally, these uninitialized d ata reside

at the end of the segment, thereby making p_memsz larger than p_filesz in the associated program

header element.

Note Section

Sometimes a vend or or system bu ilder n eeds to mark an object file with special information tha t otherpr ogram s will check for conformance, compatibility, etc. Sections of type SHT_NOTE and p rogram

header elements of type PT_NOTE can be used for this pu rpose. The note information in sections and

program header elements holds any num ber of entries, each of which is an array of 4-byte word s in the

format of the target processor. Labels app ear below to help explain note informa tion organization, but

they are not p art of the specification.

Figure 2-3: Note Information__________namesz__________descsz__________type__________name. . .__________desc. . .

__________



36/60


namesz an d name

The firs t 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, vendors u se their ow n nam e, such as XYZ Comp uter 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 firs t descsz bytes in desc hold th e note descriptor. The ABI places no constraints on a

descriptor s contents. If no descriptor is pr esent, descsz contains 0. Padding is present, if

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

in descsz .

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

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

both the name and the type to understand a descriptor. Types currently must be non-

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

To illustrate, the following note segm ent holds two 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.



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

Program Loading

As the system creates or augm ents a p rocess image, it logically copies a files segment to a virtual

memory segment. Whenand ifthe system physically reads the file dep ends on the program s execu-

tion behavior, system load, etc. A process does not requ ire a physical page unless it references the logical

page d uring execution, and processes comm only leave many p ages unreferenced. Therefore delaying

ph ysical reads frequently obviates them , improving system perform ance. To obtain this efficiency inpr actice, executable and shared object files mu st have segment images whose file offsets and virtual

add resses are congruent, modu lo the page size.

Virtual ad dresses and file offsets for the SYSTEM V architectur e segmen ts are congru ent m odu lo 4 KB

(0x1000) or larger pow ers of 2. Because 4 KB is the maximum p age size, the files will be suitable for pag-

ing regard less of ph ysical page size.

Figure 2-5: Executable File

File Offset File Virtual Ad dr ess____________________0 ELF header____________________

Program header table ____________________

Other information____________________0x100 Text segmen t 0x8048100

. . .

0x2be00 bytes 0x8073eff____________________0x2bf00 Data segment 0x8074f00

. . .

0x4e00 bytes 0x8079cff____________________0x30d00 Other information

. . .____________________

Figure 2-6: Program Header Segments

Member Text Data______________________________________________p_type PT_LOAD PT_LOAD

p_offset 0x100 0x2bf00

p_vaddr 0x8048100 0x8074f00

p_paddr unspecified unspecified

p_filesz 0x2be00 0x4e00

p_memsz 0x2be00 0x5e24

p_flags PF_R + PF_X PF_R + PF_W + PF_X

p_align 0x1000 0x1000______________________________________________

Although the examples file offsets and virtua l add resses are congr uen t mod ulo 4 KB for both text and

data, up to four file pages hold imp ure text or data (depending on p age size and file system block size).

The first text p age contains the ELF header, the program header table, and other information.



39/60


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

The first data p age has a copy of the end of text.

The last data page m ay contain file information not relevant to the running process.

Logically, the system enforces the memory p ermissions as if each segment w ere comp lete and separate;segments 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 memor y

page, the extraneous data mu st be set to zero, not the un known contents of the executable file. Impuri-

ties in the other thr ee pages are not logically part of the process image; whether th e system expun ges

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 segments mu st reside at

the virtual add resses used to build the 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 add ress change from one p rocess to another, w ithout 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 addr essing between segments, the difference

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

The following tab le 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 uta tions.

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

interpreter files segments. That is, instead of using the original executable files segment images, the sys-tem composes a mem ory image for the interpreter. 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 beginn ing. It can use this file descriptor to read and / or map th e executable

files segments into memory. Second, d epend ing on the executable file format, the system may load the

executable file into m emory instead of giving the interpreter an op en file descriptor. With the possible

exception o f the file descriptor , the interp reters initial process state matches w hat the executable file

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

either a shared object or an executab le 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 ynamic segment area u sed by

mmap(KE_OS) and related services. Consequ ently, a shared object interp reter typ ically will notconflict w ith the original executable files original segment addresses.

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

add resses from the p rogram head er table. Consequently, an executable file interp reters virtual

add resses may collide w ith the first executable file; the interp reter is respon sible for resolving

conflicts.

Dynamic Linker

When building 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 inv oke the d ynam ic linker as the pr o-

gram interpreter.

NOTE

The locations of the system provided dynamic linkers are processorspecific.

Exec(BA_OS) and the dynam ic linker coopera te to create the process image for the program, wh ichentails the following actions:

Add ing the executable files memory segments to the p rocess image;

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

Performing relocations for the executable file and its shared objects;

Closing the file descriptor that w as used to read th e executable file, if one w as given to the dyn amic

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 dat a that assist the dynam ic linker for executable and sh ared object

files. As show n above in Program Header, these data r eside in loadable segments, making th em 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 th e pr ocessor supp lement, shared objects may occup y virtual m emory

add resses that are d ifferent from the ad dresses recorded in the files program header table. The dyn amic

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 program header table, this normally 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 prog ram . 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 overhead for fun ctions that are not called. See Procedu re Linkage Table in this part for moreinformation.

Dynamic Section

If an object file participates in dynam ic linking, its program head er table will have an element of type

PT_DYNAMIC . This segment contains 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 Spe cification, 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 addresses 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 memory base address. For

consistency, files do notcontain relocation entries to correct add resses in the dynamic

structure.

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

marked mandatory, then th e dyn amic linking ar ray for an ABI-conforming file must have an entry of

that type. Likewise, optional means an entry for the tag may ap pear 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 ind ex into the table record ed in the DT_STRTAB

entry. See Shared Object Depend encies for more information abou t these nam es.

The dynamic array m ay contain multiple 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 bytes, 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 procedu re linkage table and / or the

global offset table. See this section in the pr ocessor

Documents

ELF Format