___________________________________________ EXECUTABLE AND LINKABLE FORMAT (ELF) ELF（可执行链接格式）手册 Portable Formats Specification, Version 1.1 Tool Interface Standards (TIS) ___________________________________________ 1. 目标文件(Object file) 3 序言 3 文件格式 3 数据表示 4 ELF Header 5 ELF 鉴别(Identification) 8 节 11 特殊节 18 字符串表String Table 22 符号表Symbol Table 23 符号值Symbol Values 27 重定位Relocation 27 重定位类型Relocation Types 29 2. 程序装入和动态链接PROGRAM LOADING AND DYNAMIC LINKING 33 序言 33 程序头Program Header 34 基地址Base Address 36 注释节 37 程序载入Program Loading 39 动态链接Dynamic Linking 41 动态链接器Dynamic Linker 41 动态节Dynamic Section 43 共享Object的依赖关系 47 GOT全局偏移量表Global Offset Table 49 PLT过程链接表Procedure Linkage Table 50 哈希表Hash Table 52 初始化和终止函数Initialization and Termination Functions 53 3. C LIBRARY 54
ELF: Executable and linkable formatPortable Formats Specification, Version 1.1Tool Interface Standards(TIs)Fiqures and tablesFigure 1-1: Object File FormatFigure 1-2: 32-Bit Data TypesFigure 1-3: ELF HeaderFigure 14: e ident[ Identification IndexesFigure 1-5: Data Encoding ELFDATA2LSBFigure 1-6: Data Encoding ELFDATA2MSBFigure 1-7: 32-bit Intel Architecture Identification, e identFigure 1-8: Special Section IndexesFigure 1-9: Section HeaderFigure 1-10: Section T ypes, sh typeFigure 1-11: Section Header Table Entry: Index OFigure 1-12: Section Attribute Flags, sh flagsFigure 1-13: sh link and sh info InterpretationFigure 1-14: Special SectionsFigure 1-15: String Table IndexesFigure 1-16: Symbol Table EntryFigure 1-17: Symbol Binding, ELF32 ST BINDFigure 1-18: Symbol Types, FTFFigure 1-19: Symbol Table Entry: Index OFigure 1-20: Relocation EntriesFigure 1-21: Relocatable FieldsFigure 1-22: Relocation TypesFigure 2-1: Program HeaderFigure 2-2: Segment Types, p typeFigure 2-3: Note InformationFigure 2-4: EXample Note SegmentFigure 2-5: Executable FileFigure 2-6: Program Header SegmentsFigure 2-7: Process Image SegmentsFigure 2-8: Example Shared Object Segment AddressesFigure 2-9: Dynamic StructureFigure 2-10: Dynamic Array Tags, d tagFigure 2-11: Global Offset TableFigure 2-12: Absolute Procedure Linkage TableFigure 2-13: Position-Independent Procedure Linkage TableFigure 2-14: Symbol Hash TableFigure 2-15: Hashing FunctionFigure 3-1: Iibc Contents, Names without SynonymsFigure 3-2: libc Contents, Names with SynonymsFigure 3-3: libc Contents, Global External data SymbolsTool Interface Standards(tis)Portable Formats Specification, Version 1.1PrefaceELF: Executable and Linking FormatThe Executable and linking Format was originally developed and published by UNIX System Laboratories (USL)as part of the Application Binary Interface(ABI). The Tool Interface Standards committeeTIS) has selected the evolving eLF standard as a portable object file format that works on 32-bit IntelArchitecture environments for a variety of operating systemsThe 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 recompilingAbout 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 partsPart 1, Object Files describes the elf object file format for the three main types of object filea Part 2, Program Loading and Dynamic Linking describes the object file information and systemactions that create running programsPart 3,C Library lists the symbols contained in ibsys, the standard ANSI C and iibc routines,and the global data symbols required by the libc routinesReferences to X86 architecture have been changed to Intel ArchitectureTool Interface Standards(tis)Portable Formats Specification, version 1.1OBJECT FILESIntroductionFile formatData RepresentationELF HeaderELF IdentificationMachine InformationSectionsSpecial sectionsString TableSymbol tableSymbol valuesRelocationRelocation TypesTool Interface Standards(tis)Portable Formats Specification, Version 1.1ntroductionPart 1 describes the iaBl object file format, called elF(Executable and linking Format). There are threemain types of object filesA relocatable file holds code and data suitable for linking with other object files to create an executable or a shared object filea An executable file holds a program suitable for execution; the file specifies how exec(BA_OS)createsa programs process Imagea shared object file holds code and data suitable for linking in two contexts. First, the link editor [seeld(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 imageCreated 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 areexcludedAfter the introductory material, Part 1 focuses on the file format and how it pertains to building programs. Part 2 also describes parts of the object file, concentrating on the information necessary to executea programFile formatObject files participate in program linking(building a program)and program execution(running a pro-gram). For convenience and efficiency, the object file format provides parallel views of a file\'s contentsreflecting the differing needs of these activities. Figure 1-1 shows an object file\'s organizationFigure 1-1: object File FormatLinking ViewExecutionⅤieweLf headerELF headerProgram header tableProgram header tableoptionalSection 1Segment 1Section nSegment 2Section header tableSection header tableoptionalAn elf header resides at the beginning and holds a road map describing the file\'s organization. Sections hold the bulk of object file information for the linking view: instructions, data, symbol table, relocation 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 fileTool Interface Standards(tis)Portable Formats Specification, Version 1.1ELF: Executable and linkable formatcess image(execute a program)must have a program header table; relocatable files do not need one. 4 OA program header table, if present, tells the system how to create a process image. Files used to build a pisection header table contains information describing the files sections. Every section has an entry in thetable; each entry gives information such as the section name, the section size, etc. Files used during linking must have a section header table; other object files may or may not have oneAlthough the figure shows the program header table immediately after the elF header, and the sectionNotE header 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 fileData RepresentationAs described here, the object file format supports various processors with 8-bit bytes and 32-bit architecures. Nevertheless, it is intended to be extensible to larger(or smaller)architectures. Object files therfore 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 abject file use the encod-ing of the target processor, regardless of the machine on which the file was createdFigure 1-2: 32-Bit Data TypesSize AlignmentPurposeElf32 AddrUnsigned program addressFlf32 halfUnsigned medium integerElf32 offUnsigned file offsetElf32 Swordgned large integerElf32 WordUnsigned large integerunsigned charUnsigned small integerAll data structures that the object file format defines follow the natural size and alignment guidelinesfor the relevant class. 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 an Elf32 Addr member will be alignedon a 4-byte boundary within the file上 or portability reasons,上L上 uses no bit- fieldsPortable Formats Specification, Version 1.1Tool 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. The treatment of missing information depends on context and will be specified when and if extensions are definedFigure 1-3: ELF HeaderineE工 NIDENTtypedef structunsigned char e ident [EI N-DENT];Elf32 Halfe typF,1f32 Halfe machineElf32 Worde version;e eryiElf32 offe hoffElf32 offe shoff:Elf32 Worde flags;Elf32 Halfe ehsiz∈;E1f32 IlalfElf32 Halfe panumE1f32 Halfe shentsizeElf32 Halfe shrume shstrndx:e identThe initial bytes mark the file as an object file and provide machine-independent datath which to decode and interpret the files contents. Complete descriptions appearbelow, in elF Identificatione typeThis member identifies the object file typeValueMeaningET NONEo No file typeET REL1 Relocatable fileET EXEC2 Executable fileET DYN3 Shared object fileET CORE4 Core fileET LOPROC 0xff00 Processor-specificET HIPROC 0xffff Processor-specificAlthough the core file contents are unspecified, type ET coRE is reserved to mark thefile. Values from EI LOPRoC through ET HIPRoC (inclusive) are reserved forprocessor-specific semantics. Other values are reserved and will be assigned to newobject file types as necessaryTool Interface Standards(tis)Portable Formats Specification, Version 1.1ELF: Executable and linkable formatmachineThis member\'s value specifies the required architecture for an individual fileValueMeaningEM NONENo machineEM M3at T We 32100EM SPARCSPARCEM3863ntel80386EM 68KMotorola 68000EM 885 Motorola 88000EM960Intel 80860EMM工PS8 MIPS RS3000Other values are reserved and will be assigned to new machines as necessarProcessor-specific ELF names use the machine name to distinguish them. For examplethe flags mentioned below use the prefix E- a flag named WIDGET for the EM XYZmachine would be called ef XYZ Widgete version This member identifies the object file versionValueMeaningEV NONEInvalid versionEV CURRENTCurrent versionThe value 1 signifies the original file format; extensions will create new versions withhigher numbers. The value of EV CURRENT, though given as 1 above, will change asnecessary to reflect the current version number.e entryThis member gives the virtual address to which the system first transfers control, thusstarting the process. If the file has no associated entry point, this member holds zeroe hoffThis member holds the program header table\'s file offset in bytes. If the file has noprogram header table, this member holds zero.e sheffThis member holds the section header tables file offset in bytes. If the file has no section header table, this member holds zeroe flagsThis member holds processor-specific flags associated with the file. Flag names takethe form EF machine flag. See Machine Information for flag definitionse ehsizeThis member holds the elf header\'s size in bytese phentsize This member holds the size in bytes of one entry in the files program header table; allentries are the same sizee phnumThis member holds the number of entries in the program header table. Thus the pro-duct of e phentsize and e phnum gives the table\' s size in bytes. If a file has no pro-gram header table, e phnum holds the value zeroe shentsize This member holds a section headers size in bytes a section header is one entry inthe section header table all entries are the same sizee shuiNThis member holds the number of entries in the section header table. Thus the productof e shentsize and e shum gives the section header tables size in bytes. If a filehas no section header table, e shum holds the value zeroPortable Formats Specification, Version 1.1Tool Interface Standards(TIs) ...展开详情