PE文件虚拟地址空间中绝对寻址的使用场景与原因解析

PE文件里使用绝对寻址的情况，主要集中在以下场景，背后原因和代码逻辑、编译机制直接相关：

1. 全局/静态变量的直接引用 #

• 当代码读写全局变量或静态变量时，编译器会生成指向该变量绝对虚拟地址的指令。这类变量在进程虚拟空间中的位置是固定的，但编译时无法预知PE文件最终的加载基址，因此必须靠重定位表修正地址。
• 比如C代码里int g_val; void set_val() { g_val = 10; }，编译后的指令会直接指向g_val的绝对地址，加载时如果基址和编译预设值不同，重定位表就会自动调整这个地址。

2. 非延迟加载的跨模块函数调用 #

• 调用其他DLL的导出函数时，如果未启用延迟加载机制，编译器会生成指向导入表函数地址槽的绝对寻址指令。导入表的位置在加载后是固定的，但编译时的基址可能和实际加载基址不符，所以需要重定位来修正。
• 比如调用MessageBoxA，代码里会直接引用导入表中存储该函数地址的位置，这个位置的绝对地址就得靠重定位调整。

3. 手写汇编中的硬编码地址 #

• 手写汇编代码时，如果使用mov eax, 0x12345678这类直接指定绝对地址的指令，编译器不会自动转换为RVA，只能依赖重定位表适配加载基址的变化。这种情况多见于底层系统编程或对性能要求极高的代码。

4. 自定义数据结构中的绝对指针 #

• 程序自行维护的一些数据结构，比如自定义跳转表、配置表，如果其中存储了函数或数据的绝对虚拟地址，加载时也需要重定位。比如一个函数指针数组，数组元素是各个函数的绝对地址，加载基址变化时就必须修正这些指针。

为什么要使用绝对寻址？ #

• 减少运行时开销：对于全局变量、跨模块函数这类固定位置的对象，直接使用绝对地址无需每次计算RVA+基址，能省去运行时的地址推导步骤。
• 汇编层面的直接控制：汇编编程中直接访问绝对地址是常规操作，适合需要精确控制内存访问的场景。
• 历史与兼容性：早期Windows程序模型中绝对寻址的使用更为普遍，一些遗留代码或特定编译选项会保留这种方式。

内容的提问来源于stack exchange，提问作者Dmitriy