理解bss段为啥不占磁盘空间

elf文件中的.bss段，存放未初始化的全局变量，将.data和.bss分开的理由是为了节约磁盘空间，.bss不占实际的磁盘空间，为什么.bss不占磁盘空间呢？

这里编写了一个test.c文件，gcc编译gcc test.c -o test之后，使用ls -l test 命令就可以得到可执行文件的信息，文件的带下为12696

接着我们修改源程序：

可以看到大小从12696变成了16696，与之前相比，该文件占据的大小涨了4000字节，这不就是我们的数组a[1000]的大小吗？我们所在的改动仅仅是初始化了a[1000]，让这个数组的所在段从.bss段改到了.data段。通过size test命令查看bss段的大小也减小了。这就证明了.bss段中的数据并没有占据磁盘空间，从而节约了磁盘的空间。linux环境下的c语言， 初始值为零和没有赋初始值的变量放在BSS段，因为这些值都是零，所以就不需要放到文件里面，等程序加载的时候再赋值就好了 。

int a[1000]既然不占据实际的磁盘空间(是指不占据应该分配的内存大小)，那么它的大小和符号存在哪呢？

.bss段占据的大小存放在ELF文件格式中的段表(Section Table)中，段表存放了各个段的各种信息，比如段的名字、段的类型、段在elf文件中的偏移、段的大小等信息。 我们可以通过命令readelf -S test来查看test可执行文件的段表:

这里再额外说明一个很有趣的地方，在elf文件结构中，有一个字符串表.strtab，里面存放的是elf文件中各个段的名字以及变量名等字符串，字符串表中记录了这些字符串以及对应的下标，需要用到这些字符串时，直接用偏移下标去取就行了。段表中存放的段的名字这一项，就是存的.strtab中对应字符串的偏移。

.bss段所占空间的大小存在哪里解决了，那么就剩下符号了。 符号当然对应的存在符号表.symtab中了。我们可以通过命令readelf -s test来查看：

在第51行，我们看到了定义的全局数组b[1000]，4000那一项表明数据的大小是4000字节，OBJECT代表是一个变量，GLOBAL代表是作用域是全局的。

可以得出结论：

.bss不占据实际的磁盘空间，只在段表中记录大小，在符号表中记录符号。当文件加载运行时，才分配空间以及初始化

理论上，BSS文件确实是二进制文件，和BIN文件相类似。

但是，即使同为二进制文件，也并不代表两种文件一定可以通过修改文件扩展名而通用。

刷写BIOS是非常危险的 *** 作，一旦出现问题，主板就会成砖，所以建议一定要谨慎 *** 作。

主板的官网，提供BIOS文件下载的同时，一定会提供相应的刷写工具以及教程，建议你仔细阅读后再进行 *** 作。

二进制文件中的一种段，未初始化变量记录在这里，占据的程序文件的空间不等于运行时载入内存所占据的空间大小，就是说，在bss中，比如声明一个char a[255]，那么bss中只是记录，不实际分配空间，实际空间等到运行时分配，大小是255字节。

---