我使用NASM汇编了以下代码:
global _start
section .data
var1 DD 0xA1A2A3A4 ; 4 bytes
var2 DD 0xB1B2B3B4 ; 4 bytes
section .bss
var3: RESD 1 ; 4 bytes
section .text
_start:
mov DWORD [var3], 0xC1C2C3C4
我在OllyDbg中打开文件并使其执行指令:mov DWORD [var3], 0xC1C2C3C4
。
执行此指令后,这是OllyDbg左下窗格的状态,以及内存映射:
如您所见,数据部分从地址0x00F02000开始,其大小为0x1000字节(因此var3
是数据部分的一部分)。
修改
我使用以下命令创建了目标文件:
nasm -f win32 D:\1.asm
要创建EXE文件,我使用Visual C ++ 2010链接器使用以下命令:
link D:\1.obj /OUT:D:\1.exe /ENTRY:start /SUBSYSTEM:CONSOLE
答案 0 :(得分:4)
这是Microsoft的链接器执行的优化。
PE格式规范要求为每个部分分配VirtualSize字节。 VirtualSize通常为4 KB,文件对齐倍数和Windows上的内存页面大小。由于您的.data
部分小于4 KB,因此未初始化的数据可以很容易地适应,占用“松弛”空间。
如果要引入单独的.bss
部分,那么这将使二进制文件更大并且增加加载时间而没有令人信服的理由。链接器选择将.data
和.bss
部分合并为一个。
这些附加数据(否则会进入.bss
部分)不会增加.data
部分的原始大小,因为此数据实际上并不需要存储在二进制文件中的任何位置因此,它与.bss
具有基本相同的效果。
作为Paweł Łukasik observed,MinGW的链接器不执行相同的优化。
Borland的TLINK(现在可能仅具有历史意义)从未发出.bss
部分。它总是扩展.data
部分的虚拟大小。