确定哪些目标文件导致 .dll 大小增加 [C++]

Posted 2023-02-16

技术标签:

【中文标题】确定哪些目标文件导致 .dll 大小增加 [C++]【英文标题】：Determining what object files have caused .dll size increase [C++] 【发布时间】：2009-06-01 21:10:51 【问题描述】：

我正在开发一个大型 c++ 构建的库，该库最近增长了很多。由于它的大小，导致这种大小增加的原因尚不清楚。

您有什么工具（msvc 或 gcc）建议可以帮助确定增长的来源。

编辑我尝试过的事情：Dumpbin 最终的 dll、obj 文件、创建地图文件并翻录它。

再次编辑 所以 objdump 和一个 python 脚本似乎已经完成了我想要的。

【问题讨论】：

我怀疑库和其他包含。例如，仅包含 windows.h 并在我的机器上使用一些例程会增加可执行文件的大小。可能有很多东西。问题要求的是帮助确定导致尺寸增加的原因的工具。代码库太大，无法手动检查。 【参考方案1】：

如果是 gcc，objdump。如果是视觉工作室，dumpbin。

我建议对旧（小）库与新（大）库的工具输出进行比较。

【讨论】：

我试过垃圾箱。我在数据和代码部分都显示出相当一致的增长，所以这并没有告诉我太多。你做垃圾箱没有参数吗？输出信息摘要的 IIRC，而 dumpbin /all 会更加冗长。 msdn.microsoft.com/en-us/library/kw9f57kb(VS.71).aspx 我建议将 dumpbin /all 传递到两个二进制文件的文件中，然后对它们进行比较，如果你还没有这样做的话。嗯，一个 /all 转储整个目标文件的反汇编 do 磁盘。我得到一个包含 50 万行的 .text 文件。这不可能很好地区分。我正在使用 /headers 来了解增加的内容。对不起，我自己没有尝试 /all ，我只阅读了我提供的链接，表明它不会输出反汇编。不过，使用 objdump 时，我很幸运能够转储大量信息，然后以编程方式对其进行排序以查找大尺寸的来源。如果 C++ 函数名修饰从旧库到新库是一致的，我很想尝试编写一个 perl 脚本，用符号名称的散列键填充散列表，散列旧库的符号大小值。然后检查新库中的符号是否在散列中，仅在它们至少大 10% 时打印它们，并根据大小对输出进行排序。希望你能得到一份简短的清单，列出需要手动调查的事情。【参考方案2】：

keysersoze 的回答（比较objdump 或dumpbin 的输出）是正确的。另一种方法是告诉链接器生成一个映射文件，然后比较新旧版本 DLL 的映射文件。

MSVC：link.exe/MAP GCC 和 binutils：ld -M（或 gcc -Wl,-M）

【讨论】：

【参考方案3】：

在 Linux 上，应该很容易查看是否添加了带有递归差异的新文件。他们肯定会增加图书馆的规模。然后，您可以在 Linux 上使用 size 命令行工具来获取每个新目标文件的大小并将它们汇总。然后将该总和与您的图书馆增加进行比较，并检查它的差异。

【讨论】：

目标文件的大小不一定匹配主dll大小的增加。如果您在单独的文件中有模板实例化，则每个 obj 文件都会有一个副本，但链接器会丢弃其中的许多。 @iferrorthrownewbrick 可能是这样，但新文件几乎肯定会为库贡献“一些东西”，因为它们在上一个版本中根本不存在。 ;-)【参考方案4】：

生日，

如果您有任何以前版本的目标文件，您可以运行 size 命令查看哪个段增长了吗？

几个问题：

您使用的是 *nix 平台还是 Windows 平台？您使用的是哪个编译器？最近是否更改了编译器？最近是否添加了 -g 标志？（显而易见的问题1）该对象之前是否被剥离？（明显问题2）该对象以前是否动态链接？（显而易见的问题 3）

编辑：如果代码在 SCM 下，您能否查看为您提供较小对象的源代码版本。然后比较：

find ./tree_top ( -name *.h -o -name *.cpp ) | wc -l

find ./tree_top ( -name *.h -o -name *.cpp ) -print | sort > treelist

HTH

顺便说一句请在此处发布您的发现，因为我相信很多人都对您的发现感兴趣。

干杯，

【讨论】：

两个平台，msvc90 和 gcc4，不，不，不，不。 @Igor，这还不足以提供答案！ (-: 我正在寻找增加最终文件大小的特定位置，而不是所有已更改的位置。我本可以添加一个地方，我们正在实例化大量模板，例如，该方法不会显示这些模板。