I Executable and Linkable Format (ELF) - skyfree.org

1 IExecutable and Linkable Format (ELF)ContentsPreface1 OBJECT FILESI ntroduction1-1 ELF Header1-3 Sections1-8 String Table1-16 Symbol Table1-17 Relocation1-212 PROGRAM LOADING AND DYNAMIC LINKINGI ntroduction2-1 Program Header2-2 Program Loading2-7 Dynamic Linking2-103C LIBRARYC Library3-1 IIndexIndexI-1 Tool Interface Standards (TIS) Portable Formats Specification, Version : Executable and Linkable FormatiiPortable Formats Specification, Version Tool Interface Standards (TIS)Figures and TablesFigure 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 _ i d e n t [ ]Identification Indexes 1-5 Figure 1-5:Data EncodingE L F D A T A 2 L S B1-6 Figure 1-6:Data EncodingE L F D A T A 2 M S B1-6 Figure 1-7:32-bit Intel Architecture Identification,e _ i d e n t1-7 Figure 1-8:Special Section Indexes 1-8 Figure 1-9:Section Header 1-9 Figure 1-10:Section Types,s h _ t y p e1-10 Figure 1-11:Section Header Table Entry: Index 0 1-11 Figure 1-12:Section Attribute Flags,s h _ f l a g s1-12 Figure 1-13:s h _ l i n kands h _ i n f oInterpretation 1-13 Figure 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.

2 Symbol Binding,E L F 3 2 _ S T _ B I N D1-18 Figure 1-18:Symbol Types,E L F 3 2 _ S T _ T Y P E1-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 _ t y p e2-3 Figure 2-3:Note Information 2-4 Figure 2-4:Example Note Segment 2-5 Figure 2-5: Executable File 2-7 Figure 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 _ t a g2-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:l i b cContents, Names without Synonyms 3-1 Figure 3-2:l i b cContents, Names with Synonyms 3-1 Figure 3-3:l i b cContents, Global External Data Symbols 3-2 Tool Interface Standards (TIS) Portable Formats Specification, Version : Executable and Linking FormatThe Executable and Linking Format was originally developed and published by UNIX System Labora-tories (USL) as part of the Application Binary Interface (ABI).

3 The Tool Interface Standards committee(TIS) has selected the evolving ELF standard as a portable object file Format that works on 32-bit IntelArchitecture environments for a variety of operating ELF standard is intended to streamline software development by providing developers with a set ofbinary interface definitions that extend across multiple operating environments. This should reduce thenumber of different interface implementations, thereby reducing the need for recoding and This DocumentThis document is intended for developers who are creating object or Executable files on various 32-bitenvironment operating systems. It is divided into the following three parts:Part 1, Object Files describes the ELF object file Format for the three main types of object 2, Program Loading and Dynamic Linking describes the object file information and systemactions that create running 3, C Library lists the symbols contained inl i b s y s, the standard ANSI C andl i b croutines,and the global data symbols required by thel i b to X86 architecture have been changed to Intel Interface Standards (TIS)

4 Portable Formats Specification, Version FILESI ntroduction1-1 File Format1-1 Data Representation1-2 ELF Header1-3 ELF Identification1-5 Machine Information1-7 Sections1-8 Special Sections1-13 String Table1-16 Symbol Table1-17 Symbol Values1-20 Relocation1-21 Relocation Types1-22 Tool Interface Standards (TIS) Portable Formats Specification, Version 1 describes the iABI object file Format , called ELF ( Executable and Linking Format ). There are threemain types of object fileholds code and data suitable for linking with other object files to create an execut-able or a shared object fileholds a program suitable for execution; the file specifies howe x e c(BA_OS) createsa program s process object fileholds code and data suitable for linking in two contexts.

5 First, the link editor [seel d(SD_CMD)] may process it with other relocatable and shared object files to create another objectfile. Second, the dynamic linker combines it with an Executable file and other shared objects tocreate a process by the assembler and link editor, object files are binary representations of programs intended toexecute directly on a processor. Programs that require other abstract machines, such as shell scripts, the introductory material, Part 1 focuses on the file Format and how it pertains to building pro-grams. Part 2 also describes parts of the object file, concentrating on the information necessary to executea FormatObject files participate in program linking (building a program) and program execution (running a pro-gram).

6 For convenience and efficiency, the object file Format provides parallel views of a file s contents,reflecting the differing needs of these activities. Figure 1-1 shows an object file s 1-1: Object File FormatLinking View Execution View_ _____ _ _____ELF header ELF header_ _____ _ _____Program header table Program header tableoptional_ _____ _ _____Section 1_ _____..Segment 1_ _____ _ _____Sectionn_ _____..Segment 2_ _____ _ _____.._ _____ _ _____Section header table Section header tableoptional_ _____ _ _____ AnELF headerresides at the beginning and holds a road map describing the file s the bulk of object file information for the linking view: instructions, data, symbol table, reloca-tion information, and so on.

7 Descriptions of special sections appear later in Part 1. Part 2 discussesseg-mentsand the program execution view of the Interface Standards (TIS) Portable Formats Specification, Version : Executable and Linkable FormatAprogram header table, if present, tells the system how to create a process image. Files used to build a pro-cess image (execute a program) must have a program header table; relocatable files do not need one. Asection header tablecontains information describing the file s sections. Every section has an entry in thetable; each entry gives information such as the section name, the section size, etc. Files used during link-ing must have a section header table; other object files may or may not have the figure shows the program header table immediately after the ELF header, and the sectionheader table following the sections, actual files may differ.

8 Moreover, sections and segments have nospecified order. Only the ELF header has a fixed position in the RepresentationAs described here, the object fileformatsupports various processors with 8-bit bytes and 32-bit architec-tures. Nevertheless, it is intended to be extensible to larger (or smaller) architectures. Object files there-fore represent some control data with a machine-independent Format , making it possible to identifyobject files and interpret their contents in a common way. Remaining data in an object file use the encod-ing of the target processor, regardless of the machine on which the file was 1-2: 32-Bit Data TypesName Size Alignment Purpose_ _____E l f 3 2 _ A d d r4 4 Unsigned program addressE l f 3 2 _ H a l f2 2 Unsigned medium integerE l f 3 2 _ O f f4 4 Unsigned file offsetE l f 3 2 _ S w o r d4 4 Signed large integerE l f 3 2 _ W o r d4 4 Unsigned large integeru n s i g n e d c h a r1 1 Unsigned small integer_ _____ All data structures that the object file Format defines follow the natural size and alignment guidelinesfor the relevant class.

9 If necessary, data structures contain explicit padding to ensure 4-byte alignment for4-byte objects, to force structure sizes to a multiple of 4, etc. Data also have suitable alignment from thebeginning of the file. Thus, for example, a structure containing anE l f 3 2 _ A d d rmember will be alignedon a 4-byte boundary within the portability reasons, ELF uses no Formats Specification, Version Tool Interface Standards (TIS)ELF HeaderSome object file control structures can grow, because the ELF header contains their actual sizes. If theobject file Format changes, a program may encounter control structures that are larger or smaller thanexpected. Programs might therefore ignore extra information.

10 The treatment of missing informa-tion depends on context and will be specified when and if extensions are 1-3: ELF Header# d e f i n e E I _ N I D E N T 1 6t y p e d e f s t r u c t {u n s i g n e d c h a r e _ i d e n t [ E I _ N I D E N T ] ;E l f 3 2 _ H a l f e _ t y p e ;E l f 3 2 _ H a l f e _ m a c h i n e ;E l f 3 2 _ W o r d e _ v e r s i o n ;E l f 3 2 _ A d d r e _ e n t r y ;E l f 3 2 _ O f f e _ p h o f f ;E l f 3 2 _ O f f e _ s h o f f ;E l f 3 2 _ W o r d e _ f l a g s ;E l f 3 2 _ H a l f e _ e h s i z e ;E l f 3 2 _ H a l f e _ p h e n t s i z e ;E l f 3 2 _ H a l f e _ p h n u m ;E l f 3 2 _ H a l f e _ s h e n t s i z e ;E l f 3 2 _ H a l f e _ s h n u m ;E l f 3 2 _ H a l f e _ s h s t r n d x ;} E l f 3 2 _ E h d r ;e_identThe initial bytes mark the file as an object file and provide machine-independent datawith which to decode and interpret the file s contents.