因为对齐。
XNU 强制映射二进制文件部分的每个段都与平台的页面大小对齐。在 x86_64 上,这是 0x1000 字节,在 arm64 上,这是 0x4000 字节(即使硬件支持 0x1000)。如果某些段的数据必须与某个偏移量对齐,那么就必须有某物在填补两者之间空白的文件中 - 通常为零。
现在,如果您的二进制文件是 48KB,那么它的段可能如下所示:
LC 00: LC_SEGMENT_64 Mem: 0x000000000-0x100000000 File: Not Mapped ---/--- __PAGEZERO
LC 01: LC_SEGMENT_64 Mem: 0x100000000-0x100004000 File: 0x0-0x4000 r-x/r-x __TEXT
LC 02: LC_SEGMENT_64 Mem: 0x100004000-0x100008000 File: 0x4000-0x8000 rw-/rw- __DATA_CONST
LC 03: LC_SEGMENT_64 Mem: 0x100008000-0x10000c000 File: 0x8000-0xc000 rw-/rw- __DATA
LC 04: LC_SEGMENT_64 Mem: 0x10000c000-0x100010000 File: 0xc000-0xc110 r--/r-- __LINKEDIT
对于 0x4000 的对齐,这已经是最小布局。但如果你使用 Intel,你可以通过传递强制链接器使用 0x1000-Wl,-segalign,0x1000
给编译器。这应该会生成一个只有 12KB 左右的二进制文件:
LC 00: LC_SEGMENT_64 Mem: 0x000000000-0x100000000 File: Not Mapped ---/--- __PAGEZERO
LC 01: LC_SEGMENT_64 Mem: 0x100000000-0x100001000 File: 0x0-0x1000 r-x/r-x __TEXT
LC 02: LC_SEGMENT_64 Mem: 0x100001000-0x100002000 File: 0x1000-0x2000 rw-/rw- __DATA_CONST
LC 03: LC_SEGMENT_64 Mem: 0x100002000-0x100003000 File: 0x2000-0x3000 rw-/rw- __DATA
LC 04: LC_SEGMENT_64 Mem: 0x100003000-0x100004000 File: 0x3000-0x3110 r--/r-- __LINKEDIT
如果您想进一步优化二进制文件,则需要删除段。通过导入和链接,您真正可以摆脱的唯一一个是__DATA_CONST
,您可以通过针对 macOS Mojave(或更早版本)使用-mmacosx-version-min=10.14
。这将使您剩下 8KB 多一点的空间:
LC 00: LC_SEGMENT_64 Mem: 0x000000000-0x100000000 File: Not Mapped ---/--- __PAGEZERO
LC 01: LC_SEGMENT_64 Mem: 0x100000000-0x100001000 File: 0x0-0x1000 r-x/r-x __TEXT
LC 02: LC_SEGMENT_64 Mem: 0x100001000-0x100002000 File: 0x1000-0x2000 rw-/rw- __DATA
LC 03: LC_SEGMENT_64 Mem: 0x100002000-0x100003000 File: 0x2000-0x20f0 r--/r-- __LINKEDIT
如果您追求尽可能最小的可执行文件,您可以进一步放弃__DATA
甚至可能__LINKEDIT
,但是您必须大幅更改代码以仅发出原始系统调用,而不使用动态链接器等。
对于任何现实世界的应用程序,我还想说这些零实际上并不重要。给定四个映射段,它们使用的空间永远不会超过 48KB。二进制越大,零所占的百分比就越小。
至于分布,答案很明显:xz
.
压缩上述二进制文件会产生:
- 48KB 二进制文件为 776 字节。
- 12KB 二进制文件为 736 字节。
- 8KB 二进制文件为 684 字节。