免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
12下一页
最近访问板块 发新帖
查看: 123751 | 回复: 13

[内核入门] 通过elf各种重定位类型,理解不同场合的链接过程 [复制链接]

论坛徽章:
13
15-16赛季CBA联赛之八一
日期:2016-07-08 21:00:1415-16赛季CBA联赛之同曦
日期:2017-02-15 14:26:1515-16赛季CBA联赛之佛山
日期:2017-02-20 14:19:2615-16赛季CBA联赛之青岛
日期:2017-05-07 16:49:1115-16赛季CBA联赛之广夏
日期:2017-07-30 09:13:1215-16赛季CBA联赛之广东
日期:2018-07-05 22:34:3615-16赛季CBA联赛之江苏
日期:2018-09-03 12:10:2115-16赛季CBA联赛之上海
日期:2018-09-25 03:49:2215-16赛季CBA联赛之广东
日期:2018-09-25 04:09:12
发表于 2016-11-24 18:12 |显示全部楼层
本帖最后由 _nosay 于 2016-11-24 18:12 编辑

    最近为了理解elf格式规范中的各种重定位类型,晕了。跑出去玩了几天,终于为每种重定位类型,找到了对应的case。elf规范总共定义了10种重定位类型,之所以需要这么多种不同类型的重定位信息,是由于如下原因:
    ① 硬件对变量和函数的寻址方式不同,寻找变量要求绝对地址,寻找函数要求相对地址;
    ② 不同场合下,程序员对最终可执行文件或动态库的期望不一样(位置无关、动态库函数重定位延迟),从而加了不同的编译选项(比如-fPIC、-Ox等);
    ③ C语言的static、extern特性,导致不同特性的变量或函数地址可以被确定的时机不同;
    ④ 内核加载可执行文件,约定从固定地址0x80480000开始,但加载.so的起始地址无法约定(一个可执行程序只有一个main(),但可能依赖多个动态库)。
    疑问:那整个系统中,可执行程序也不只一个呀,都约定从相同的起始地址加载,不会冲突吗?
    因为每个进程访问的都是虚拟地址,由内核在背后负责将不同进程的相同虚拟地址,映射到不同的实际物理地址(属于内核范畴,不理解没关系,不影响对本贴关键内容的理解)。

  • 静态链接/动态链接简单理解
    .c文件中的代码最终被执行,需要经历如下过程:
    ① 编译:词法解析 → 语法解析 → 静态链接
    ② 加载:加载可执行文件 → 可执行文件启动或执行时,加载依赖的.so文件 → 动态链接

    本帖仅关注静态链接、动态链接过程,静态链接与动态链接区别:
    ① 静态链接处于将1个或多个.o文件“拼凑”成可执行文件阶段,处理对象是文件,文件中的代码区没有只读属性,链接过程中可以直接修改;动态链接处于可执行文件或.so文件已被加载到内存阶段,处理对象是内存,内核为代码区所在的内存区域设置了只读属性,如果代码区有内容需要重定位,需要在编译或静态链接时,事先准备一个间接位置(加载到内存不会被设置只读属性),动态链接是对该间接位置进行重定位。
    ② 通过下图可以看出,静态链接将.o的各个节“撕开”,属性相同的节“拼凑”为可执行文件的段;动态链接是将“整个”.so文件安排在与可执行文件镜像相独立的位置(图中最简化了.o、.so、可执行文件的内容,用于说明静态链接与动态链接的区别,它们的内容远远不止.data、.text)。
    另外,.so文件还涉及到位置无关(-fPIC)、延迟加载的选择(应该是跟优化级别有关),接下来即将详细总结。
    ld.png
    编译阶段,.o文件的全局变量位置不确定,因为这时无法确定还有其它哪些.o文件,以及链接器将来会按什么顺序“排列”这些.o文件(见静态链接示意图),链接阶段,.so文件的全局变量位置也不确定,是因为这时不知道.so文件将来被加载到进程空间的什么位置(见动态链接示意图)。既然不能确定,只能瞎写,但计算机世界一是一、二是二,瞎写完一定要留下一个“交待”(重定位项),等将来时机成熟时,再补上正确的值。

  • R_386_32
    table_R_386_32.png
    R_386_32计算公式:S+A。
    S:对于.o文件,表示全局变量被链接器安排的位置或其所在xx节的起始位置;对于.so文件,表示全局变量被加载到的虚拟地址。
    A:被重定位处的原始值(4字节,由重定位项offset指向)。

    晕了,没关系,先看具体的case(看完R_386_32,再理解其它重定位类型就有感觉了):
    6处的指令“a1 00 00 00 00”,由于此时无法预测g1经过加载后的地址,就先写一个假地址0,16处指令“a1 04 00 00 00”,由于此时无法预测g3经过链接后的位置,就先写一个假地址4。但0、4都不是编译器随意写上的,因为随后做重定位计算时要将它们作为A值。
    另外,g4是未初始化的static全局变量,所以被“放在”.bss段,所以重定位项指定用.bss节位置作为S值(“放在”加了引号,是因为.bss在文件中不占空间,只有一个结构用于指示加载到内存时,它应该处于的位置以及大小,比如一万个0,在程序要执行时,才需要为这些0分配内存为它们所代表的变量占据位置,而在文件中不需要分配一万个字节,它只需要能提供一个简短的信息,提供加载时能正确的分配一万个字节并填充为0即可)。
    R_386_32.png

    为了验证图中提出的问题,继续分析链接该.o文件得到的.so文件:
    R_386_32_so.png
    可以看出,对.o留下的不同类型重定位项,处理结果不一样,暂时只关注g1、g3,链接器(ld)在.so文件中为g1仍然留了一条R_386_32重定位项,而为g3留了一条R_386_RELATIVE重定位项,再次处理这两条重定位项,就已经是加载到内存后由动态链接器完成了(ld-linux.so.2),计算公式中的成员含义也会改变,比如S表示符号加载到的虚拟地址。
    不是说内核会为代码对应的内存区域设置只读属性么,加载到内存后还能修改的了吗?
    准确的说,内核将代码加载到内存,需要做很多处理,设置只读只是其中一个,并且在完成重定位之后:“加载→重定位→设置只读→执行”。


    上述这种不加-fPIC选项编译得到的.so文件,只是单纯将一个完整的二进制文件分隔成可执行文件和.so文件,将重定位操作延迟到加载时了,并没有发挥.so关键设计意图:.so共享。
    因为各个进程的虚拟空间使用情况不一样,会导致这种情况:进程A的100地址空闲,并将libc.so加载到100开始的虚拟空间,将.so镜像中各个重定位处依据100地址计算重定位值,进程B的200地址空闲,如果直接将内存中已经存在的libc.so镜像映射到200位置,之前按100地址修改的重定位处,就不满足进程B的要求了,所以只能再加载一份libc.so并映射到自己的虚拟空间(稍后说明的位置无关就是为了解决这个问题)。

  • R_386_PC32
    table_R_386_PC32.png
    R_386_PC32计算公式:S+A-P。
    S:对于.o文件,表示链接阶段全局变量被安排的位置或其所在xx节起始位置;
         对于.so文件,表示全局变量被加载到的虚拟地址。
    A:被重定位处的原始值(4字节,由重定位项offset指向)。
    P:重定位项中的offset值。对于.o、.so文件,表示被重定位处在.o、.so文件中的偏移;对于可执行文件,表示被重定位处被加载到的虚拟地址。

    10处的指令“e8 fc ff ff ff”,由于此时无法预测f1()经过加载后的地址,就先写一个假地址-4,15处指令“e8 fc ff ff ff”,由于此时无法预测f2()经过链接后的位置,就先写一个假地址-4。
    -4-P解释:首先P代表被重定位处位置(对于10处指令,P=11,对于15处指令,P=16),则P+4分别代表下一条指令位置15、1a(运行时就是下一条指令的虚拟地址),而硬件在处理机器码e8(call指令)时,不是将紧接着后面的4字节直接作为跳转地址,而是要加上下一条指令的地址,所以重定位时只好事先-(P+4)。
    对比说明R_386_32的case,g1的A值为0,g3的A值为4,而这里两条重定位项的A值都是-4,因为它们的差距体现在这两处,P值本身就不同。
    R_386_PC32.png
    为什么f1()、f2()都有重定位项,fun()没有?
    重定位项的生成是根据调用,而不是定义。

    另外,有了对R_386_32的理解基础,可以想象将该.o文件链接成.so文件,链接器会如何处理重定位项,并动手验证一下(注意:有些电脑编译.so文件必须加-fPIC选项,一方面可能跟系统是32/64位有关,另一方面可能跟编译器版本有关)
    R_386_PC32_so.png
    非static函数fun()调用static函数f3(),为什么直接使用相对偏移即可
    当前.so加载位置确定,f3()加载位置就确定了,不能确定fun()位置(同链接阶段无法通过R_386_32重定位类型确定g1位置一个道理),那么此时计算的相对位置不也失效了吗?

  • R_386_GOT32
    table_R_386_GOT32.png
    R_386_GOT32计算公式:G+A-P。
    G:链接阶段生成的GOT表位置。
    A:被重定位处的原始值(4字节,由重定位项offset指向)。
    P:重定位项中的offset值,表示被重定位处在.o文件中的偏移。

    对于G的解释,提到GOT表,什么是GOT表?
    通过R_386_32、R_386_PC32的说明可知,不加-fPIC选项编译得到的.so文件,并没有给计算机带来什么实惠,因为它的代码根据前一个进程对它的加载地址完成重定位后,之后其它进程不能直接将它映射到自己的虚拟空间使用,因为它们对重定位计算的基准不一样。
    got表正是用于将需要重定位的内容剥离出来,从大范围(整个.so的代码区域)汇聚到小范围(.got表),即将加载地址对代码区域的影响,转移到对.got表的影响。所以说,.so共享并不是完全的共享,各个进程仍然有一个.got表的副本,而.got表往往很小。

    主要利用两个技巧:
    ① 在程序编写阶段,虽然不知道以下两条指令真正执行后ebx寄存会得到什么值,但能确定它的含义是当时eip寄存器的值,那么跟这条指令相对位置固定的运行时地址,在逻辑上都能在编译阶段“获知”:
        call L1
        L1: pop ebx
    ② 那么,在.so文件中相对于指令区域确定位置生成一个.got表,.so被执行时.got表的绝对地址也是可以“获知”的。这样,就可以用.got表项的绝对地址,覆盖原本在指令区域的重定位处,而.got表中存放将来才能确定的最终重定位的符号地址。

     一份代码区域,多份.got表:
    PIC.png

    理解mmap()函数,有助于更深入理解上图,在此只大概说明(涉及内核的内存管理和文件系统):
    mmap.png
    ① 假设进程A先将libc.so映射到自己的一块虚拟空间,当首次访问这块区间时发生缺页异常,分配物理页面并读入内容,然后建立映射。接着,进程B也将libc.so映射到自己的一块虚拟空间,首次访问这块区间仍然会发生缺页异常,但与其建立映射的物理页面,就不用再重新分配读入了。从而,物理内存只需要一份.so的内容,就可以供A、B两个进程使用。
    ② 思维敏锐的可能会发现一个问题:.so文件中如果有全局变量,被多个进程共享,不是会相互干扰吗?
        COW(写时复制):内核为虚拟页面、物理页面都设置了一些属性,比如如果对某个虚拟页面进行写操作,就重新分配一个物理页面,复制内容并重新建立映射(为.so数据区分配的页面,就具有这样的属性)。
    ③ 各个进程将.so文件映射到自己的虚拟空间,数据区、代码区的相对位置,仍然保持和刚链接过后一致,所以在代码区向.got的重定位计算仍然有效,只不过动态链接器为不同进程向.got表初始化全局变量的地址时,要向.got表进行写操作,导致每个进程有一个.got副本。

    编译说明R_386_32时使用的case代码,加上-fPIC选项,就能看到编译器为g1、g2变量在.o文件中生成了R_386_GOT32重定位项以及为g3、g4变量在.o文件中生成了R_386_GOTOFF重定位项,稍后说明)
    R_386_GOT32.png
    6、b处两条指令执行后,ecx寄存器会得到.got表加载地址,为什么?
    ① 前面已经说明过R_386_PC32重定位类型,7处经过这种类型重定位后,执行时会跳转到__x86.get_pc_thunk.cx,得到b处指令的加载地址(CPU没有提供直接获取当前ip的指令,所以利用call会将返回地址压栈的特点);
    ② R_386_GOTPC,提示链接器创建.got表,并修改d处的值,保证执行时用它加ecx寄存器可以得到.got表地址(可以通过R_386_GLOB_DAT类型分析过程,编译得到的.so验证):
        通过①可能确定,执行过6处指令后ecx得到的b处指令的加载地址,拿什么和它相加可以得到.got表位置呢?
        +A:从ecx所指位置往后推2字节(机器码“81 c1”),就到了被重定位处(重定位项中的offset/规范文档中的P);
        +G-P:再向后推.got表相对此处的距离,就到.got表了。
        注意:$0x2只是作为链接器计算重定位值的A,在执行时就被G-P-2覆盖了,不要疑惑为什么要从ecx减2,它的含义根本就不是减数。

  • R_386_GLOB_DAT
    table_R_386_GLOB_DAT.png
    R_386_GLOB_DAT计算公式:S。

    对比R_386_32、R_386_GOT32,就是在编译.o文件时,加了-fPIC选项,R_386_GOT32重定位类型就是希望将重定位处从代码区域转移到.got表,链接阶段创建.got表,完成代码区域重定位,添加对.got表项的重定位项(转移≠消除)。
    将说明R_386_GOT32时编译得到的.o文件,链接成.so文件:
    R_386_GLOB_DAT.png
    ① 532、537处(对应.o文件中6、b处)指令,确实可以将.got表位置计算到ecx寄存器中(不过是结束位置,后面指令取.got表项地址时,用的是负偏移,可能不同编译器不一样吧,用开始位置、结束位置计算,道理是一样的)
    ② g1、g2的重定位类型变成R_386_GLOB_DAT,它是用于告诉动态链接器,在确定g1、g2地址时,放到它们的.got表项里(0x1fe8、0x1ff4)。

  • R_386_PLT32
    table_R_386_PLT32.png
    R_386_PLT32计算公式:L+A-P

    与R_386_GOT32、R_386_GLOB_DAT道理相似,R_386_PLT32、R_386_JUMP_SLOT也是为支持PIC定义的重定位类型,前者面向的是全局变量,后者面向函数。
    不过由于为了支持“动态库函数重定位延迟”,在.got.plt表跳转前,还多了一层.plt表跳转,.plt表里是一些链接器为重定位函数生成的跳转代码片段,计算公式中的L表示为重定位函数生成的跳转代码片段在.so文件中的位置(可以通过R_386_JUMP_SLOT类型分析过程,编译得到的.so验证)。
    R_386_PLT32.png

  • R_386_JUMP_SLOT
    table_R_386_JUMP_SLOT.png
    R_386_JUMP_SLOT计算公式:S

    相比链接器对R_386_GLOB_DAT重定位项的处理,R_386_JUMP_SLOT重定位项的处理过程更复杂,不光在.so文件中创建.got.plt表,还为f1()、f2()对应生成了f1@pltf2@plt代码片段,并将代码中对f1()、f2()的调用,分别替换成对f1@pltf2@plt的调用,同时对f1()、f2()的重定位类型变成了R_386_JUMP_SLOT,这个重定位类型不会在.so文件一加载时就被动态链接器处理,而是调用f1()、f2()的指令首次被执行时,才进行重定位操作(比如我喜欢学习内核,但我目前的工作跟内核并没有多大关系,聪明的人都是等工作需要的时候,再学)。

    不防看一下f1()首次被调用的过程:
    ① 562地址处的指令执行后,ebx寄存器指向.got.plt表开始位置0x2000;
    ② 568、56d处原本对f1()、f2()的调用,被替换为对f1@pltf2@plt的调用:
        <f1@plt>:
        410: jmp  *0x18(%ebx)    ;0x2018,f1()在.got.plt表中占据的表项位置,表项内容初始值为0x416,即首次执行这条指令时,相当于“jmp 0x416”
        416: push $0x18
        41b: jmp  3d0 <_init+0x2c>

        有点奇怪,首次从410→416干嘛要特意绕个圈?
        这个圈只会在第一次执行f1@plt时才会绕,当416、41b处指令调用动态链接器,将f1()地址填到.got.plt表项0x2018后,以后再执行410处指令时,就相当于“jmp f1”了。即:
        第一次执行f1@plt:410 → 416、41b → f1()
        第二次执行f1@plt:410 → f1()
    而且链接器将所有调用f1()的地方都替换成调用f1@plt了,所以410→416这个圈,只会绕一次,不过即使这样,每次调用f1(),也要先“call <fl@plt>”,所以延迟加载虽然“聪明”,但有得也有失。
    R_386_JUMP_SLOT.png

  • R_386_COPY
    table_R_386_COPY.png
    R_386_COPY计算公式:冇

    初始化的全局变量和未初始化全局变量,被安排的位置是不同的,分别在.data、.bss,那么,如果某个模块通过extern引用了另外一个模块中定义的全局变量,编译阶段是不知道这个变量是否被初始化了,因为它根本看不到其它.c文件,所以就暂时把该变量安排在.bss,等链接阶段得知它如果有初始值的话,就依据此重定位项,修改一下.bss相应位置的值。
    R_386_COPY.png

  • R_386_RELATIVE
    table_R_386_RELATIVE.png
    R_386_RELATIVE计算公式:B+A
    B:.so文件加载地址。

    分析R_386_32类型时,已经说明过R_386_RELATIVE,静态变量位置在链接阶段可以确定在.so文件中的偏移,那么计算它的加载地址,自然是加上.so文件的加载地址B就可以了。

  • R_386_GOTOFF
    table_R_386_GOTOFF.png
    R_386_GOTOFF计算公式:S+A-GOT

    编译说明R_386_32时使用的case代码,加上-fPIC选项,就能看到编译器为g3、g4变量在.o文件中生成了R_386_GOTOFF重定位项(在分析R_386_GOT32类型时提到过,基于静态变量相对于.so文件加载地址,距离固定,利用GOT表位置进行重定位)
    R_386_GOTOFF.png

  • R_386_GOTPC
    table_R_386_GOTPC.png
    R_386_GOTPC计算公式:GOT+A-P

    分析R_386_GOT32类型时,已经说明过R_386_GOTPC,它与R_386_32类似,只不过一个用于重定位变量位置,一个用于重定位.got表位置。

  • 总结
    把对各种重定位类型的理解放在同一张表格对比,它们之间的区别就暴露的赤裸裸,再也不扑朔迷离了:
  (为了xx,需要在xx阶段xx,前一阶段提供准备,后一阶段完成计算,或变换为另一种计算方式)
    REL_type.png

  • 参考
      http://www.cnblogs.com/catch/p/3857964.html
      http://blog.csdn.net/stonesharp/article/details/12943963
      http://blog.csdn.net/wuhui_gdnt/article/details/51035557
      http://blog.csdn.net/wuhui_gdnt/article/details/51094732
      http://blog.csdn.net/wuhui_gdnt/article/details/51160465
      http://jzhihui.iteye.com/blog/1447570
      http://blog.csdn.net/yuyin86/article/details/10239479

1-2008-07-25-TN05.ELF.Format.Summary.pdf

852.96 KB, 下载次数: 270

评分

参与人数 1信誉积分 +10 收起 理由
nswcfd + 10 很给力!

查看全部评分

论坛徽章:
20
程序设计版块每日发帖之星
日期:2015-08-17 06:20:00程序设计版块每日发帖之星
日期:2016-07-16 06:20:00程序设计版块每日发帖之星
日期:2016-07-18 06:20:00每日论坛发贴之星
日期:2016-07-18 06:20:00黑曼巴
日期:2016-12-26 16:00:3215-16赛季CBA联赛之江苏
日期:2017-06-26 11:05:5615-16赛季CBA联赛之上海
日期:2017-07-21 18:12:5015-16赛季CBA联赛之青岛
日期:2017-09-04 17:32:0515-16赛季CBA联赛之吉林
日期:2018-03-26 10:02:16程序设计版块每日发帖之星
日期:2016-07-15 06:20:0015-16赛季CBA联赛之江苏
日期:2016-07-07 18:37:512015亚冠之萨济拖拉机
日期:2015-08-17 12:21:08
发表于 2016-11-25 14:29 |显示全部楼层
下子写帖子之前可以先把PS1修改一下,这样就不用给每张图打马赛克了

也可以使用script命令来记录程序的输出。或者使用screen/tmux等终端软件的“截屏”功能。

论坛徽章:
13
15-16赛季CBA联赛之八一
日期:2016-07-08 21:00:1415-16赛季CBA联赛之同曦
日期:2017-02-15 14:26:1515-16赛季CBA联赛之佛山
日期:2017-02-20 14:19:2615-16赛季CBA联赛之青岛
日期:2017-05-07 16:49:1115-16赛季CBA联赛之广夏
日期:2017-07-30 09:13:1215-16赛季CBA联赛之广东
日期:2018-07-05 22:34:3615-16赛季CBA联赛之江苏
日期:2018-09-03 12:10:2115-16赛季CBA联赛之上海
日期:2018-09-25 03:49:2215-16赛季CBA联赛之广东
日期:2018-09-25 04:09:12
发表于 2016-11-25 15:10 |显示全部楼层
回复 2# nswcfd

嗯嗯,我是远程别人电脑的,改成啥他不会怪我呢

论坛徽章:
13
15-16赛季CBA联赛之八一
日期:2016-07-08 21:00:1415-16赛季CBA联赛之同曦
日期:2017-02-15 14:26:1515-16赛季CBA联赛之佛山
日期:2017-02-20 14:19:2615-16赛季CBA联赛之青岛
日期:2017-05-07 16:49:1115-16赛季CBA联赛之广夏
日期:2017-07-30 09:13:1215-16赛季CBA联赛之广东
日期:2018-07-05 22:34:3615-16赛季CBA联赛之江苏
日期:2018-09-03 12:10:2115-16赛季CBA联赛之上海
日期:2018-09-25 03:49:2215-16赛季CBA联赛之广东
日期:2018-09-25 04:09:12
发表于 2016-11-25 19:04 |显示全部楼层

论坛徽章:
20
程序设计版块每日发帖之星
日期:2015-08-17 06:20:00程序设计版块每日发帖之星
日期:2016-07-16 06:20:00程序设计版块每日发帖之星
日期:2016-07-18 06:20:00每日论坛发贴之星
日期:2016-07-18 06:20:00黑曼巴
日期:2016-12-26 16:00:3215-16赛季CBA联赛之江苏
日期:2017-06-26 11:05:5615-16赛季CBA联赛之上海
日期:2017-07-21 18:12:5015-16赛季CBA联赛之青岛
日期:2017-09-04 17:32:0515-16赛季CBA联赛之吉林
日期:2018-03-26 10:02:16程序设计版块每日发帖之星
日期:2016-07-15 06:20:0015-16赛季CBA联赛之江苏
日期:2016-07-07 18:37:512015亚冠之萨济拖拉机
日期:2015-08-17 12:21:08
发表于 2016-12-02 11:50 |显示全部楼层
phrack.org, very good!

论坛徽章:
6
2015年辞旧岁徽章
日期:2015-03-05 16:13:092015年迎新春徽章
日期:2015-03-05 16:13:092015小元宵徽章
日期:2015-03-06 15:58:1815-16赛季CBA联赛之浙江
日期:2016-11-05 14:38:4115-16赛季CBA联赛之新疆
日期:2016-11-11 18:38:06
发表于 2016-12-06 21:43 |显示全部楼层
不同的软硬件平台会有不同的重定位类型,基本的就两种:绝对定位与相对定位。如x64平台上有64位的绝对定位与32位的相对定位

论坛徽章:
0
发表于 2017-02-23 00:23 |显示全部楼层
这篇真牛~之前研究都不懂,看这篇就懂了

论坛徽章:
0
发表于 2017-02-26 22:04 |显示全部楼层
good summary, thanks!

论坛徽章:
13
15-16赛季CBA联赛之八一
日期:2016-07-08 21:00:1415-16赛季CBA联赛之同曦
日期:2017-02-15 14:26:1515-16赛季CBA联赛之佛山
日期:2017-02-20 14:19:2615-16赛季CBA联赛之青岛
日期:2017-05-07 16:49:1115-16赛季CBA联赛之广夏
日期:2017-07-30 09:13:1215-16赛季CBA联赛之广东
日期:2018-07-05 22:34:3615-16赛季CBA联赛之江苏
日期:2018-09-03 12:10:2115-16赛季CBA联赛之上海
日期:2018-09-25 03:49:2215-16赛季CBA联赛之广东
日期:2018-09-25 04:09:12
发表于 2018-02-08 16:29 |显示全部楼层

论坛徽章:
13
15-16赛季CBA联赛之八一
日期:2016-07-08 21:00:1415-16赛季CBA联赛之同曦
日期:2017-02-15 14:26:1515-16赛季CBA联赛之佛山
日期:2017-02-20 14:19:2615-16赛季CBA联赛之青岛
日期:2017-05-07 16:49:1115-16赛季CBA联赛之广夏
日期:2017-07-30 09:13:1215-16赛季CBA联赛之广东
日期:2018-07-05 22:34:3615-16赛季CBA联赛之江苏
日期:2018-09-03 12:10:2115-16赛季CBA联赛之上海
日期:2018-09-25 03:49:2215-16赛季CBA联赛之广东
日期:2018-09-25 04:09:12
发表于 2018-07-08 01:22 |显示全部楼层
关于R_386_PC32,帖子里提了一个问题,表示当时我对这种重定位类型的理解有错误。
f2()的调用处,需要对应一个R_386_PC32重定位项,这是很容易理解的,因为它是extern的,链接的时候才知道f2()指令块的开始位置,相应的,call指令中的偏移值,也必须等链接时才可以确定。
疑惑在f1()和f3(),它们的指令块都在f.o的.text节,而链接是将各个.o文件的.text节整个搬到最终的目标文件中,不是被打碎了再搬进去的,所以f1()同f3()一样,与fun()的相对位置,在编译阶段就能确定下来,即使f1()可以被别的模块调用,也影响不了这一点,那凭什么对f3()的调用不需要设置重定位项,f1()的调用却需要?
那是因为R_386_PC32这种重定位原本只是用于extern函数调用的,而非static函数默认也有extern属性,所以就多此一举的为f1()调用处加了重定位项,将call指令中相对位移的计算推迟到了链接时,虽然不影响正确性,但是对学习的人好有干扰性,很容易让人觉得是由于static非static的区别,却又不能完全解释的通,因为本质是根据extern非extern的区别来的,直到今天才发现!
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP