为什么可执行文件这么大？ （为什么死代码没有被删除？）

Question

编译并链接此文件会生成 1-KiB 可执行文件：

#pragma comment(linker, "/Entry:mainCRTStartup") // No CRT code (reduce size)
#pragma comment(linker, "/Subsystem:Console")    // Needed if avoiding CRT

#define STRINGIFIER(x)    func##x
#define STRINGIFY(x)      STRINGIFIER(x)
#define G   int STRINGIFY(__COUNTER__)(void) { return __COUNTER__; }

int mainCRTStartup(void) { return 0; }  // Does nothing

#if 0
    // Every `G' generates a new, unused function
    G G G G G G G G G G G G G G G G G G G G G G G G G G G G G G G G
    G G G G G G G G G G G G G G G G G G G G G G G G G G G G G G G G
#endif

当您将 #if 0 更改为 #if 1 时，输出大小 <翻倍至 2 KiB。

尽管我的命令行选项包含我能想到的所有优化，但迄今为止所有版本的 Visual C++ 似乎都是这样做的：

/Ox /MD /link /fixed /OPT:ICF /OPT:REF

而且，具体来说，我没有包含任何调试信息。

有谁知道为什么 /OPT:REF 不会导致链接器删除未使用的函数？

Answer 1

从广义上讲......编译器在“对象记录”中生成代码，其中包含一堆汇编代码和支持信息。链接器将这些对象记录链接在一起以创建可执行文件。

通常，编译器会为整个源文件创建一个单个对象记录。在这种情况下，链接器只能决定是否链接整个对象记录。由于对象记录中至少有一个函数被使用，因此它必须链接所有函数。

在某些编译器上，您可以告诉它为每个函数生成单独的对象记录（一个对象文件可以有多个对象记录）。在这种情况下，链接器可以决定省略一些从未被调用过的对象记录。

来自 /OPT 的 Microsoft 文档：

/OPT：参考

<块引用>

LINK 默认删除未引用的封装函数。如果对象是使用 /Gy 选项编译的，则该对象包含打包函数 (COMDAT)。这种优化称为传递 COMDAT 消除。要覆盖此默认值并在程序中保留未引用的 COMDAT，请指定 /OPT:NOREF。您可以使用 /INCLUDE 选项来覆盖特定符号的删除。

/Gy 编译器选项启用函数级链接。

作为参考，这个功能在 gcc 中也存在：

-ffunction-sections
-fdata-sections

<块引用>

如果目标支持任意部分，请将每个函数或数据项放入输出文件中自己的部分中。函数的名称或数据项的名称决定了输出文件中的节的名称。

在链接器可以执行优化的系统上使用这些选项，以提高指令空间中引用的局部性。大多数使用 ELF 对象格式和运行 Solaris 2 的 SPARC 处理器的系统都具有具有此类优化的链接器。 AIX 将来可能会有这些优化。

仅当这样做可以带来显着好处时才使用这些选项。当您指定这些选项时，汇编器和链接器将创建更大的目标文件和可执行文件，并且速度也会变慢。如果指定此选项，您将无法在所有系统上使用“gprof”，并且如果同时指定此选项和 ​​-g，则可能会出现调试问题。

以及 ld 中的伴随选项：

--GC 部分

<块引用>

启用未使用的输入部分的垃圾收集。在不支持此选项的目标上，它将被忽略。此选项与 -r 或 --emit-relocs 不兼容。可以通过在命令行上指定 --no-gc-sections 来恢复默认行为（不执行此垃圾收集）。