NASM中.bss部分中声明的变量是否被加载到进程的数据部分而不是进程的bss部分?

时间:2017-07-11 08:35:08

标签: assembly x86 nasm

我使用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左下窗格的状态,以及内存映射:

enter image description here

如您所见,数据部分从地址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

1 个答案:

答案 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部分的虚拟大小。

相关问题