首页 > 代码库 > ELF格式的重定位原理分析
ELF格式的重定位原理分析
前面有篇文章分析了ELF格式,也只是让我们对目标文件有了一个大概的了解,并没有说明一个十分重要的问题:重定位,今天重新看了下重定位的资料,终于弄懂了重定位的过程,下面来做一个分析。
我们将使用下面两个源代码中的文件a.c和b.c展开分析:
//a.c extern int shared; int main() { int a=100; swap(&a,&shared); } //b.c int shared=1; void swap(int *a,int *b) { *a^=*b^=*a^=*b; }
使用命令:gcc -c a.c b.c生成两个可重定位目标文件a.o和b.o,下面就要使用链接器将a.o和b.o链接起来生成执行文件ab,我们分析的就是这个过程。
1.链接的过程
现在的链接器一般都是两步链接,也就是说整个链接过程分两步。
1)符号解析,主要使用ELF里面的符号表节来完成,不做描述。
2)重定位:一旦链接器完成符号解析这一步,它就把代码中的每个符号引用和定义联系起来。在此时,链接器就知道它的输入目标文件中的代码节和数据节的确切大小。现在就可以重定位了,在这个步骤中将合并输入模块,并为每个符号分配运行时地址。重定位由两步组成:
- 重定位节和符号定义:在这一步中,链接器将所有相同类型的节合并为同一类型的新的聚合节。例如输入文件a.o的.text节和b.o中的.text节合并为可执行文件ab中的.text节。然后链接器将运行时存储器地址赋值给新的聚合节。当这一步完成时,程序中的每个指令和全局变量都有唯一的运行时存储器地址。
- 重定位节中的符号引用:在这一步中,链接器修改代码节和数据节中对每个符号的引用,试的他们指向正确的运行时地址。为了执行这一步,链接器依赖于重定位条目。稍后我们来重点分析这一步骤的具体实现过程。
我们看到上面是a.o的各个段的分布情况,看到VMA列全都是0,VMA就是虚拟地址的意思,说明a.o中的节确实没有分配存储器运行时地址,根据上面描述,可执行文件ab中应该分配了虚拟地址,事实确实证明了这点:
我们发现VMA不再是0。可执行文件的代码段映射到08048094,数据段映射到08049108。
2.重定位的具体实现分析
先来看下重定位条目的内容:
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000001c R_386_32 shared
00000027 R_386_PC32 swap
OFFSET TYPE VALUE
0000001c R_386_32 shared
00000027 R_386_PC32 swap
OFFSET的意义:要修改的位置在.text节的偏移量
TYPE:重定位类型
VALUE:重定位符号的名称
R_386_32(绝对寻址修正): objdump -d a.o
18: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp)
1f: 00
1f: 00
movl指令要将shared的地址送到esp+4的位置,但是此时并不知道shared的地址,所以就先放00000000。在重定位条目中的第一项偏移是1c,刚好对应00000000。所以重定位的过程就是修改这个偏移处的内容。其实这个决定寻址修正很简单,只是书上各种符号公式看的让人迷惑。
修正过程:
假设shared符号的运行时地址是0x8049108,即ADDR(shared)=0x8049108。
要该修的位置的地址:就将00000000替换为ADDR(shared)即可。
R_386_PC32(相对寻址xiuzheng):ojbdump -d a.o
26: e8 fc ff ff ff call 27 <main+0x27>
相对寻址的意思就是相对当前IP位置跳转,call实现近转移,当前指令的ip+跳转位移=目标地址
我们先看可执行文件ab的反汇编代码:
也就是说0x8048bf+x=0x80480c8,算得x=9,正好是指令的操作数。
假设P是待修改的位置的虚拟地址,S是符号实际虚拟地址,那么P+4+x=S,所以x=S-P-4,即x=0x8048c8-4-0x8048bb=9.
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。