ELF文件之一——
ELF文件整体布局
下图是后来例子中main.o和main.elf的布局。
其中,只有elf header的位置是固定的,固定在文件开始,其它部分的位置都不确定。
比如下面的main.o布局中,.text .comment .shstrtab两个节在前面,而section header table在后面
正常流程应该是由elf header找到section header table,然后,基于该表,定位其它的节。
main.o是Reloc文件,没有program header;main.elf是exec文件,有program header。
main.elf文件的symtab和strtab多了一些内容,这些内容是因为ld阶段没有指定链接脚本,使用了默认链接脚本的原因,默认链接脚本中有一些symbol。
main.elf的text段比main.o的text段多了28字节,这个还没搞清楚?
ELF Header layout
e_ident format
实际工程输出结果
main.c
int main() { ; }
main.o elf header
编译sparc-elf-gcc.exe -c main.c -o main.o
e_ident部分(前16字节)可以看出,是01-32位,02-大端,01-ELF01版本
其余部分,第二行
红色为e_type,01表示Reloc(01-Reloc,02-Exe,03-Shared)
黄色为e_machine,02表示sparc
蓝色为e_version,版本为1
绿色为e_entry,入口点虚拟地址为0
黑色为e_phoff,program header table file offset,为0,表示没有
其余部分,第三行
红色为e_shoff,section header table file offset,为0x90=144
黄色为e_flags,处理器相关标识
蓝色为e_ehsize,ELF header size in bytes,32位的为0x34=52
绿色为e_phentsize,Program header table entry size,程序头表的大小,因为没有,所以为0
黑色为e_phnum,Program header table entry count,程序头表项目数量,没有,为0
白色为e_shentsize,Section header table entry size,分区头表表项的大小,0x28=40,是每个项目40字节,一共8个项目,那么共320字节
其余部分,第四行
红色为e_shnum,Section header table entry count,分区头表项目数量,为8
黄色为e_shstrndx,Section header string table index,分区头字符表索引,为5,表示shstrtab在section header中的索引,用处?
main.o elf header简略版
下面是简略版,只关注重要的信息
0x18为e_entry,入口点虚拟地址,为0,因为是o文件,所以没有?是的
0x1c黄色为e_phoff,program header table file offset,为0,表示没有,因为是o文件?对于Reloc文件,program头表是可选的;而对于Exec文件,是强制的。
0x2a黄色高2字节为e_phentsize,Program header table entry size,程序头表的大小,因为没有,所以为0
0x2c黄色低2字节为e_phnum,Program header table entry count,程序头表项目数量,没有,为0
0x20蓝色为e_shoff,section header table file offset,为0x90=144
0x2e蓝色为e_shentsize,Section header table entry size,分区头表的大小,0x28=40
0x30蓝色为e_shnum,Section header table entry count,分区头表项目数量,为8
main.o的text节
elf header后紧跟的是text节,一共5条机器指令,共20个字节
下图是反汇编结果:
main.o的comment节
main.o没有data和bss节,后面紧跟comment节,如何知道是commnet节呢?这是从readelf结果中看出来的
这个段主要是版本控制信息This section holds version control information.
main.o的shstrtab节
comment节后是section header string table节,包含所有节名的字符串
main.o的section header
由elf header可知,section header偏移为0x90,每个entry的大小固定为0x28=40字节,每个entry占4字节,共10个enty。
第一个entry是固定为空的,第二个entry是text节。
红色为sh_name,这里其实是shstrtab中字符串的索引,0x1B正好对应.text字符串,字符串以\0结尾,上图0x00和0x2E的右侧字符表示都为.,但其中一个.为\0。
黄色为sh_type,01表示PROGBITS
蓝色为sh_flags,是一个位量,表示allocatable和executable
蓝色后4个字节为sh_addr,表示执行时的虚拟地址
绿色为sh_offset,表示在本文件中的偏移,为0x34。
黑色为sh_size,表示本节的大小为0x14=20,5条机器指令
绿色下面的四个字节表示sh_addralign,为4字节对齐
黑色下面的四个字节表示sh_entsize,若节中包含一个表格,那么,表示表格entry的大小,比如symtab节的这个值为0x10=16,即每个symbol的大小为16字节。对于strtab和shstrtab两个虽然也是表格,但该值为0,推测是由于string可以由\0区分,不需要表格的行。
readelf的结果:
symtab
symbol table符号表,每个符号占16字节
每个符号格式如下:
main.o共有8个符号,第1个符号为空,第8个符号为main
红色为name,4字节,数值为name在strtab中的索引
红色后面为value,4字节
黄色为size,4字节,main符号大小为20字节,即main函数的大小
绿色的高4bit为bind,低4位为type,bind表示符号是全局的1、局部的0等属性,type表示符号是文件4、函数2、段3等属性
黑色的为st_shndx,这个为该符号在节头表中的所属节的索引,1表示属于节头表索引1,即text
readelf的结果,下图最后一列即为st_shndx,有些是ABS绝对地址,就不属于任意节,像main函数属于索引1,即text
nm的结果
sparc-elf-nm main.o a *ABS* T main
main.elf
链接生成sparc-elf-ld.exe main.o -nostartfiles -o main.elf
elf header部分:
红色为program header offset,0x34,program header entry size=0x20,num=1
program header部分:
黄色为type,1=LOAD加载类型,
黄色后面4字节为segment段偏移(关于节section和段segment,reloc文件里叫节,exec将各reloc文件的节合并在一起叫段,节包含在段里面)
绿色为虚拟地址,后面4字节为物理地址
黑色为filesz,黑色后面4字节为memsz
main.elf的text段的大小变为0x30了,不知道为什么,后面增加的部分全为0。
symtab和strtab增加了许多,是因为使用了默认的链接脚本(因为没有指定链接脚本,所以使用了默认的,-vobose可以看到),多了很多符号。
program header readelf output
section header readelf output,可以看出main.elf相比main.o文件的节头表中text data bss节的地址增加了4000 0000的起始。
附录:
main.o
reference:
https://www.cnblogs.com/gatsby123/p/9750187.html
https://segmentfault.com/a/1190000016766079
http://refspecs.linuxbase.org/elf/elf.pdf
ELF文件之一——的更多相关文章
- ELF文件
ELF文件格式是一个开发标准,各种UNIX系统的可执行文件都采用ELF格式,它有三种不同的类型: 可重定位的目标文件 可执行文件 共享库 现在分析一下上一篇文章中经过汇编之后生成的目标文件max.o和 ...
- linux实践之ELF文件分析
linux实践之ELF文件分析 下面开始elf文件的分析. 我们首先编写一个简单的C代码. 编译链接生成可执行文件. 首先,查看scn15elf.o文件的详细信息. 以16进制形式查看scn15elf ...
- elf文件中的.plt .rel.dyn .rel.plt .got .got.plt的关系
.plt的作用是一个跳板,保存了某个符号在重定位表中的偏移量(用来第一次查找某个符号)和对应的.got.plt的对应的地址 .rel.dyn重定向表,在程序启动时就需要重定位完成. .rel.plt保 ...
- 实例分析ELF文件动态链接
参考文献: <ELF V1.2> <程序员的自我修养---链接.装载与库>第6章 可执行文件的装载与进程 第7章 动态链接 <Linux GOT与PLT> 开发平台 ...
- 实例分析ELF文件静态链接
参考文献: <ELF V1.2> <程序员的自我修养---链接.装载与库>第4章 静态链接 开发平台: [thm@tanghuimin static_link]$ uname ...
- ldconfig报错 :libstdc++.so.6.0.18-gdb.py不是一个elf文件
今天安装wxWidgets,输入ldconfig竟然提示 /usr/lib64/libstdc++.so.6.0.18-gdb.py 不是一个elf文件,开头魔数错误 摸不着头脑,上网搜了一下,有说是 ...
- axf、elf文件转换成bin、hex脚本工具
在嵌入式开发过程中常常遇到将axf或elf文件转换成bin的情况,大家都知道通过gnu toolchain中的objcopy和keil中的fromelf能做到.可是为了这么一个小事而记住复杂的选项以及 ...
- 为什么ELF文件的加载地址是0x8048000
在一个进程的虚拟地址空间中,ELF文件是从0x8048000这个地址开始加载的,为什么会是这个地址? 回答:用命令ld --verbose可以看到0x08048000,ld的默认脚本用这个地址作为EL ...
- ELF文件数据布局探索(1)
作为一名Linux小白,第一次看到a.out这个名字,感觉实在是奇怪,搜了一下才知道这是编译器输出的默认可执行文件名 然后vi一下,哇,各种乱码,仔细看看,发现了三个清晰的字符ELF.继续搜索, 第一 ...
- bin文件和elf文件
ELF文件格式是一个开放标准,各种UNIX系统的可执行文件都采用ELF格式,它有三种不同的类型: 可重定位的目标文件(Relocatable,或者Object File) 可执行文件(Executab ...
随机推荐
- SpringCloud-Hystrix原理
Hystrix官网的原理介绍以及使用介绍非常详细,非常建议看一遍,地址见参考文档部分. 一 Hystrix原理 1 Hystrix能做什么 通过hystrix可以解决雪崩效应问题,它提供了资源隔离.降 ...
- http GET 和 POST 请求的优缺点和误区 --前端优化
Get和Post在面试中一般都会问到,一般的区别:(1)post更安全(不会作为url的一部分,不会被缓存.保存在服务器日志.以及浏览器浏览记录中)(2)post发送的数据更大(get有url长度限制 ...
- Tesseract-OCR-v5.0中文识别,训练自定义字库,提高图片的识别效果
1,下载安装Tesseract-OCR 安装,链接地址https://digi.bib.uni-mannheim.de/tesseract/ 2,安装成功 tesseract -v 注意:安装后, ...
- Codeforces Round #615 (Div. 3) 题解
A - Collecting Coins 题意: 给你四个数a,b,c,d,n.问你是否能将n拆成三个数A,B,C,使得A+a=B+b=C+c. 思路: 先计算三个数的差值的绝对值abs,如果abs大 ...
- .net core 不是开源的么 作为菜 不能贡献源码 只有 欣赏额
step one 去download一份 与前辈在一起
- Idea破解至2089年
我是用的版本是2018.3.6,别的朋友使用的是2019的某个版本,不过关都不影响破解 下载jar包:链接:https://pan.***baidu.***com/s/1aRR0***2YNI9jew ...
- MYGUI3.2改造——与HGE结合,实现资源打包
其实这个有点标题党的意思.MYGUI本身有资源打包的接口,可以实现从内存读取文件. 而HGE也提供了资源打包的功能(不过HGE的资源文件管理比较弱).把MYGUI的接口接到HGE上就可以实现MYGUI ...
- Redis(八):zset/zadd/zrange/zrembyscore 命令源码解析
前面几篇文章,我们完全领略了redis的string,hash,list,set数据类型的实现方法,相信对redis已经不再神秘. 本篇我们将介绍redis的最后一种数据类型: zset 的相关实现. ...
- Centos与Ubuntu
共同点 1.两个系统都分别有桌面系统与服务器系统,不过ubuntu的桌面从外观上来看要比centos的漂亮 不同点 1.centos中新建的普通用户是没有sudo权限的,如果想让普通用户拥有sudo权 ...
- Spring(四)核心容器 - BeanDefinition 解析
前言 在上篇文章中,我们讨论了 refresh 的前四个方法,主要是对 ApplicationContext 上下文启动做一些准备工作.原计划是对接下来的 invokeBeanFactoryPostP ...