c - Microsoft C/C++ 链接器优化未能丢弃未使用的代码/数据

Question

我正在编写一个包含不同压缩算法的 C++ 库，并允许用户指定一种特定的算法，然后在用户调用 compress()/Uncompress() 时使用该算法。

问题:我正在使用的一些外部库(例如 zlib)完全是 C 语言，并且由于某种原因，链接器不会像您一样优化所有 zlib 函数和数据'预计。

示例:如果用户选择希望使用 bzip，则没有指向 zlib 的代码路径，因此不应在最终二进制文件中链接/包含任何 zlib 代码。事实上，当查看/VERBOSE 链接器输出或生成的 .map 文件时，包装 zlib 的 C++ 类甚至被链接器丢弃。然而，二进制文件中仍然包含大约 30KB 的 zlib 代码。

测试重现:一个简单的控制台应用程序，其 main 返回 0，但在 Visual Studio 项目中包含 zlib 源文件，也会添加额外的约 30KB 代码。显然根本没有调用任何 zlib 函数的代码路径，那么为什么它仍然包含在可执行文件中？ map 文件中的 Zlib 符号:

0001:00000000       _adler32                   00401000 f   adler32.obj
0001:00002470       __tr_stored_block          00403470 f   trees.obj
0001:00002510       __tr_flush_block           00403510 f   trees.obj
...
0002:00001cc0       _z_errmsg                  0040bcc0     zutil.obj
0002:00002330       __dist_code                0040c330     trees.obj
0002:00002530       __length_code              0040c530     trees.obj
0002:00002720       _inflate_copyright         0040c720     inftrees.obj
0002:000039a0       _deflate_copyright         0040d9a0     deflate.obj
0002:00005a68       ??_C@_00CNPNBAHC@?$AA@     0040fa68     gzlib.obj
0002:00005a6c       ??_C@_0BF@CJFPCCEG@incompatible?5version?$AA@ 0040fa6c     zutil.obj
0002:00005a84       ??_C@_0N@DFPGLBGC@buffer?5error?$AA@ 0040fa84     zutil.obj
0002:00005a94       ??_C@_0BE@OGGJBMCE@insufficient?5memory?$AA@ 0040fa94     zutil.obj
0002:00005aa8       ??_C@_0L@HAHMBNLP@data?5error?$AA@ 0040faa8     zutil.obj
0002:00005ab4       ??_C@_0N@MKKNPMJD@stream?5error?$AA@ 0040fab4     zutil.obj
0002:00005ac4       ??_C@_0L@KIJFAKBJ@file?5error?$AA@ 0040fac4     zutil.obj
0002:00005ad0       ??_C@_0L@FNAOCBOG@stream?5end?$AA@ 0040fad0     zutil.obj
0002:00005adc       ??_C@_0BA@MOKMMFOD@need?5dictionary?$AA@ 0040fadc     zutil.obj
...
0001:00000270       _crc32_little              00401270 f    CIL library: CIL module
0001:00000530       _flush_pending             00401530 f    CIL library: CIL module
0001:00000580       _longest_match             00401580 f    CIL library: CIL module
0001:000006e0       _fill_window               004016e0 f    CIL library: CIL module
0001:00000920       _deflate_stored            00401920 f    CIL library: CIL module
0001:00000c10       _deflate_fast              00401c10 f    CIL library: CIL module
0001:00001000       _deflate_slow              00402000 f    CIL library: CIL module
0001:00001510       _init_block                00402510 f    CIL library: CIL module
0001:00001590       _pqdownheap                00402590 f    CIL library: CIL module
0001:00001670       _gen_bitlen                00402670 f    CIL library: CIL module
0001:00001870       _gen_codes                 00402870 f    CIL library: CIL module
0001:000018f0       _build_tree                004028f0 f    CIL library: CIL module
0001:00001af0       _scan_tree                 00402af0 f    CIL library: CIL module
0001:00001bd0       _send_tree                 00402bd0 f    CIL library: CIL module
0001:00002150       _build_bl_tree             00403150 f    CIL library: CIL module
0001:00002220       _send_all_trees            00403220 f    CIL library: CIL module
0001:00002760       _compress_block            00403760 f    CIL library: CIL module
0001:00002b40       _detect_data_type          00403b40 f    CIL library: CIL module
0001:00002bb0       _bi_flush                  00403bb0 f    CIL library: CIL module
0001:00002c30       _copy_block                00403c30 f    CIL library: CIL module

请求推测/帮助:我不是链接器专家，但看来罪魁祸首是 const 数组形式的数据。例如，由于 zlib 的 deflate.c 中第 131 行定义了一个数组表，因此引入了所有 CIL 模块和一些其他函数:

local const config configuration_table[10] = {
/*      good lazy nice chain */
/* 0 */ {0,    0,  0,    0, deflate_stored},  /* store only */
/* 1 */ {4,    4,  8,    4, deflate_fast}, /* max speed, no lazy matches */
/* 2 */ {4,    5, 16,    8, deflate_fast},
/* 3 */ {4,    6, 32,   32, deflate_fast},

/* 4 */ {4,    4, 16,   16, deflate_slow},  /* lazy matches */
/* 5 */ {8,   16, 32,   32, deflate_slow},
/* 6 */ {8,   16, 128, 128, deflate_slow},
/* 7 */ {8,   32, 128, 256, deflate_slow},
/* 8 */ {32, 128, 258, 1024, deflate_slow},
/* 9 */ {32, 258, 258, 4096, deflate_slow}}; /* max compression */

链接器因此可以看到对函数的引用，并将所有它们也链接起来。

有人知道这是为什么吗？如果我将 zlib 和其他相关库重建为 C++，我的库会工作得更好吗？是否存在一种解决方案可供我使用，使我的库能够成功地仅链接到所需的库，而不是拉动所有其他压缩库？

感谢任何帮助!

Answer 1

我遇到了同样的问题，我可以通过添加 /Gw 编译器开关来修复它。它将从最终的可执行文件中删除未使用的全局数据。更多信息请点击:https://blogs.msdn.microsoft.com/vcblog/2013/09/11/introducing-gw-compiler-switch/