System V Application Binary Interface (1)
2015-09-28 17:27
489 查看
摘自:http://www.sco.com/developers/gabi/1998-04-29/ch4.intro.html
Introduction
This chapter describes the object file format, called ELF (Executable and Linking Format). There are three main types of object files.A relocatable file holds code and data suitable for linking with other object files to create an executable or a shared object file.
An executable file holds a program suitable for execution; the file specifies how
exec(BA_OS) creates a program's process image.
A shared object file holds code and data suitable for linking in two contexts. First, the link editor [see
ld(BA_OS)] processes the shared object file with other relocatable and shared object files to create another object file. Second, the dynamic linker combines it with an executable file and other shared objects to create a process image.
Created by the assembler and link editor, object files are binary representations of programs intended to be executed directly on a processor. Programs that require other abstract machines, such as shell scripts, are excluded.
After the introductory material, this chapter focuses on the file format and how it pertains to building programs. Chapter 5 also describes parts of the object file, concentrating on the information necessary to execute a program.
File Format
Object files participate in program linking (building a program) and program execution (running a program). For convenience and efficiency, the object file format provides parallel views of a file's contents, reflecting the differing needs of those activities.Figure 4-1 shows an object file's organization.
Figure 4-1: Object File Format
|
|
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 the chapter. Chapter 5 discusses
segments and the program execution view of the file.
A program header table tells the system how to create a process image. Files used to build a process image (execute a program) must have a program header table; relocatable files do not need one. A
section header table contains information describing the file's sections. Every section has an entry in the table; each entry gives information such as the section name, the section size, and so on. Files used during linking must have a section header
table; other object files may or may not have one.
Although the figure shows the program header table immediately after the ELF header, and the section header table following the sections, actual files may differ. Moreover, sections
and segments have no specified order. Only the ELF header has a fixed position in the file.
Data Representation
As described here, the object file format supports various processors with 8-bit bytes and either 32-bit or 64-bit architectures. Nevertheless, it is intended to be extensible to larger (or smaller) architectures. Object files therefore represent some controldata with a machine-independent format, making it possible to identify object files and interpret their contents in a common way. Remaining data in an object file use the encoding of the target processor, regardless of the machine on which the file was created.
Figure 4-2: 32-Bit Data Types
Name | Size | Alignment | Purpose |
---|---|---|---|
Elf32_Addr | 4 | 4 | Unsigned program address |
Elf32_Off | 4 | 4 | Unsigned file offset |
Elf32_Half | 2 | 2 | Unsigned medium integer |
Elf32_Word | 4 | 4 | Unsigned integer |
Elf32_Sword | 4 | 4 | Signed integer |
unsigned char | 1 | 1 | Unsigned small integer |
Name | Size | Alignment | Purpose |
---|---|---|---|
Elf64_Addr | 8 | 8 | Unsigned program address |
Elf64_Off | 8 | 8 | Unsigned file offset |
Elf64_Half | 2 | 2 | Unsigned medium integer |
Elf64_Word | 4 | 4 | Unsigned integer |
Elf64_Sword | 4 | 4 | Signed integer |
Elf64_Xword | 8 | 8 | Unsigned long integer |
Elf64_Sxword | 8 | 8 | Signed long integer |
unsigned char | 1 | 1 | Unsigned small integer |
objects, to force structure sizes to a multiple of 4 or 8, and so forth. Data also have suitable alignment from the beginning of the file. Thus, for example, a structure containing an
Elf32_Addrmember will be aligned on a 4-byte boundary within the file.
For portability reasons, ELF uses no bit-fields.
相关文章推荐
- MPChartLib绘制曲线图
- android 关于屏幕的设置(FullScreen、notitle)等等
- webapp的favicon应该怎样组织代码
- Android学习:实现复杂的列表项
- android内存管理
- Android 5.x的Activity过渡动画.
- Cocos2d-x 3.0final 终结者系列教程04-引擎架构分析
- 【android】开发笔记系列:行为篇
- Android结构和Framework启动流程
- AttributeError: 'WebDriver' object has no attribute
- Android 批量打包 -- 美团解决方案
- Android 二维码 生成和识别
- Android生成带LOGO图片二维码的方法
- cocos2d AABB碰撞检测
- Android-通过自定义ViewPager来高仿土巴兔选择装修风格效果(中间放大效果)
- 很好的一篇关于xcode的学习文章
- Android Studio系列教程六--Gradle多渠道打包
- Cause: org/gradle/api/publication/maven/internal/DefaultMavenFactory
- ARC Objective-c的内存管理
- iOS9 3D Touch iOS 教程 ShortcutItem使用