为什么不优化可执行文件中的填充字节？答案

【问题标题】：Why aren't padding bytes in executables optimized?为什么不优化可执行文件中的填充字节？
【发布时间】：2021-04-07 19:06:45
【问题描述】：

当我创建一个小的 Mac Mach-O 可执行文件时，例如用 C 编写的“Hello World”，由于对齐填充，它的大小约为 48k。但与此同时，我可以在 .bss 部分定义 100k 的零（例如，通过指定 100k 字符的静态数组），它只向磁盘上的可执行文件添加了几个字节。

我想知道为什么填充（我想它只在加载后才起作用）没有以某种方式“打包”。

【问题讨论】：

【解决方案1】：

您似乎不了解填充的作用：确保对象的大小满足约束条件，例如是特定数字的倍数。填充字节的值通常不重要，但它们的存在是必不可少的。

分配给 ELF（比如）.bss 部分的对象的情况正好相反：它们的值很重要，但它们的大小不需要通过它们的磁盘表示来反映。此外，这些对象的值仅通过将它们分配给 .bss 的事实来建立，因此实际上，每个对象在二进制文件中的内存表示大小都消耗 O(1) 空间。

附录： 可以想象，可以设计一种二进制格式来承载压缩数据，这样这种填充确实是在磁盘上压缩的。人们只能推测为什么这种格式不流行，但我认为至少部分答案是未压缩二进制格式的简单性和加载速度比相对少量的节省空间更有价值。压缩格式可以实现。

【讨论】：

你已经回答了为什么一些大的东西可以在可执行文件中占用很少的空间，但问题是问一些东西在可执行文件中占用很多空间——它问为什么 prima facie 过多的零字节确实出现在可执行文件中。
@EricPostpischil，OP 似乎很满意将其可执行文件的大小归因于填充，我认为没有理由对这种解释提出异议。问题是为什么填充没有在磁盘上被压缩，因为其他数据可以被描述为以压缩形式表示，所以比较是有序的。尽管如此，我还是添加了一些 cmets 来讨论其他一些相关问题，这些问题对于 OP 来说可能不如我认为的那么明显。
这几乎没有划伤表面。我期待内核开发人员不得不说的答案。就像“我们不想解析二进制文件进行解压，因为它引入了安全漏洞”。或“..因为我们测量了悲观化；出于那个人为的原因。”。或者“..因为我们不在乎你关心的小 KB”。现在我们仍然处于困境中
@v.oddou，这个答案挑战了问题的前提。如果您想回答一个类似的、更有根据的问题，那么欢迎您提出这样的问题。或者，如果您有自己的答案，当然欢迎您发表。