Clang生成的可执行文件9成以上为NULL字节，如何缩减文件体积

你碰到的可执行文件体积虚高，和无效代码、调试信息无关，核心是MacOS平台PIE格式Mach-O的段对齐规则导致的：

• PIE（位置无关可执行程序）要求所有可加载段（__TEXT、__DATA_CONST、__DATA）的虚拟地址、磁盘偏移必须和系统页大小（当前环境为16KB）严格对齐，才能支持内核零拷贝映射加载。
• 哪怕每个段里实际有效数据只有几百到一千多字节，相邻段之间的空隙也必须填充NULL字节凑够16KB对齐边界，最终形成三个独立的16KB磁盘块，加上__LINKEDIT段的实际内容，刚好和你测到的50224字节逻辑大小完全吻合。
• 普通strip命令只能删除符号表、调试信息类内容，完全不会改动段偏移和对齐填充的NULL字节，所以执行后文件大小不会有任何变化。

按优化效果从高到低排列，所有操作均可通过系统自带的clang链接参数实现，不需要额外安装第三方工具：

• 调整段对齐粒度（通用低副作用方案）
  编译时给链接器传递对齐参数，把段的对齐粒度从默认16KB（系统页大小）降到4KB，不需要关闭PIE的安全防护机制。在原有编译命令的链接参数部分追加：
  -Wl,-segalign,0x1000
  调整后每个段的对齐空隙会从16KB缩小到4KB，原本三个段占用48KB的空间会缩减到12KB左右，整个文件最终大小能降到14KB上下。
  唯一权衡：因为对齐粒度小于系统页大小，内核加载时会对段内容做一次内存拷贝，相比零拷贝有极其微小的加载开销，对KB级的小程序完全感知不到。
• 关闭非必要安全机制（体积最优方案）
  如果这个工具仅用于本地个人使用，不需要ASLR内存随机化防护，可以直接关闭PIE特性，彻底取消段的页对齐要求。具体修改编译参数：
  1. 去掉原有参数里的-fPIE -fPIC，替换为-fno-PIE
  2. 链接时追加参数-Wl,-no_pie
     调整后段的对齐粒度会降到512字节甚至更小，段之间的填充空隙可以忽略不计，最终文件大小会降到3-4KB，和实际有效数据的大小几乎一致。
     权衡：关闭ASLR会降低内存攻击的防护等级，不适合用于对外分发的、安全敏感的程序。
• 合并独立段（减少对齐次数）
  目前程序有3个独立的可加载段，每个段都要单独预留一次对齐空隙。如果把__DATA_CONST、__DATA段的内容合并到__TEXT段的同一连续空间，就只需要留一次对齐空隙，能省下两个段的填充空间。通过链接参数做段重定向：
  -Wl,-rename_section,__DATA_CONST,__got,__TEXT,__got
  调整后三个段的16KB填充会缩减为单个16KB块，最终文件大小能降到18KB左右。
  权衡：合并段后，原本给数据段设置的只读/可写内存保护会失效，整个内存页会被设置为可读可写可执行，内存安全防护等级会下降。
• 强化strip规则（仅作辅助优化）
  普通strip之所以没效果，是因为默认规则只会删除部分调试符号，不会清理符号表的占位空间。可以使用严格的strip参数进一步压缩__LINKEDIT段的大小：
  strip -x -S bin/getargv
  这个操作最多能把__LINKEDIT段从1072字节压缩到几百字节，完全解决不了段对齐填充带来的体积问题，只能作为辅助优化手段。

你看到du -h显示文件占用52K，是因为文件系统默认按照4KB/8KB的块大小计算磁盘占用，逻辑文件大小会向上取整到块大小的倍数。等按照上面的方法把文件逻辑大小缩到几KB之后，du的显示也会同步降到4K或者8K，不会再出现52K的冗余占用。

内容的提问来源于stack exchange，提问作者Camden Narzt