相关疑难解决方法(0)

作为链接器输入的文件称为对象文件.链接器生成一个Image文件,该文件又被加载器用作输入.

来自" Microsoft可移植可执行文件和通用对象文件格式规范 "的模糊

RVA(相对虚拟地址).在图像文件中,将项目的地址加载到内存后,从中减去图像文件的基地址.项目的RVA几乎总是与其在磁盘上的文件位置(文件指针)不同.

在目标文件中,RVA的意义不大,因为未分配内存位置.在这种情况下,RVA将是一个部分内的地址(在本表后面描述),稍后在链接期间将重定位应用于该地址.为简单起见,编译器应该只将每个部分中的第一个RVA设置为零.

VA(虚拟地址).与RVA相同,但不删除图像文件的基址.该地址称为"VA",因为Windows为每个进程创建了一个独立的VA空间,与物理内存无关.对于几乎所有目的,VA应仅被视为地址.VA不像RVA那样可预测,因为加载程序可能无法将图像加载到其首选位置.

即使在读完这篇文章之后,我仍然没有得到它.我有很多问题.任何人都可以用实际的方式解释它.请遵守Object File&Image File所述的术语.

我所知道的就是地址

• 在目标文件和图像文件中,我们都不知道确切的内存位置,所以
• 生成对象文件时的汇编程序计算相对于部分.data和.text(对于函数名称)的地址.
• 链接器将多个目标文件作为输入生成一个Image文件.在生成时,它首先合并每个目标文件的所有部分,并在合并它时重新计算相对于每个部分的地址偏移量.并且,没有像全球抵消那样的东西.

如果我知道有什么问题,请纠正我.

编辑:

在阅读弗朗西斯给出的答案之后,我清楚了解物理地址,VA和RVA是什么以及它们之间的关系.

所有变量和方法的RVAs必须在重定位期间由链接器计算.那么,(方法/变量的RVA值)==(它从文件开头的偏移量)？一定是真的.但令人惊讶的是,它没有.为什么这样？

我用选中此PEView 上c:\WINDOWS\system32\kernel32.dll,结果发现:

1. RVA和FileOffset一直相同,直到Sections的开头.(.text这是dll的第一部分).
2. 从年初.text通过.data,.rsrc直到最后一节的最后一个字节(.reloc)RVA&的FileOffset是不同的.并且第一部分的第一个字节的RVA"始终"显示为0x1000
3. 有趣的是,每个部分的字节在FileOffset中是连续的.我的意思是另一个部分从一个部分的最后一个字节的下一个字节开始.但是如果我在RVA中看到同样的事情,那么这是一个部分的最后一个字节和下一部分的第一个字节之间的巨大差距.

我猜:

1. 所有,第一个(.text此处)部分之前的数据字节"不"实际加载到进程的VA空间中,这些数据字节仅用于定位和描述这些部分.它们可以被称为"元部分数据".

   因为它们没有加载到VA空间的过程中.术语RVA的使用也没有意义,这就是为什么RVA == FileOffset这些字节的原因.

2. 以来,

   • RVA术语仅对将实际加载到VA空间的那些字节有效.
   • 的字节.text,.data,.rsrc,.reloc是这样的字节.
   • 而不是从RVA开始,0x00000PEView软件是从它开始的 …