用于分析 C/C++ 中过多代码大小的技术或工具有哪些？应用程序？
我有一个 C++ 库，它可以生成比我真正期望的更大的代码。从不到 50K 行的源代码中，我获得了几乎 4 MB 的共享对象和推动 9 的静态存档。这是有问题的，因为库二进制文件非常大，而且更糟糕的是，即使是链接到它的简单应用程序通常也会获得 500 到 1000代码大小为 KB。使用 -Os 等标志编译库会有所帮助，但效果并不是很大。
我还尝试过 GCC 的 -frepo 命令（尽管我见过的所有文档都表明在 Linux 上，collect2 无论如何都会合并重复的模板）以及模板上的显式模板实例化，这些模板似乎“可能”被重复很多，但没有无论哪种情况都有实际效果。当然，我说“可能”是因为，与任何类型的分析一样，像这样的盲目猜测几乎总是错误的。
是否有某种工具可以轻松分析代码大小，或者我可以通过其他方式找出是什么占用了这么多空间，或者更一般地说，我应该尝试其他任何事情？在 Linux 下工作的东西将是理想的，但我会采取我能得到的。
I have a C++ library that generates much larger code that I would really expect for what it is doing. From less than 50K lines of source I get shared objects that are almost 4 MB and static archives pushing 9. This is problematic both because the library binaries are quite large, and, much worse, even simple applications linking against it typically gain 500 to 1000 KB in code size. Compiling the library with flags like -Os helps this somewhat, but not really very much.
I have also experimented with GCC's -frepo command (even though all the documentation I've seen suggests that on Linux collect2 will merge duplicate templates anyway) and explicit template instantiation on templates that seemed "likely" to be duplicated a lot, but with no real effect in either case. Of course I say "likely" because, as with any kind of profiling, blind guessing like this is almost always wrong.
Is there some tool that makes it easy to profile code size, or some other way I can figure out what is taking up so much room, or, more generally, any other things I should try? Something that works under Linux would be ideal but I'll take what I can get.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您想了解可执行文件中放入了什么内容，请询问您的工具。打开 ld 链接器的 --print-map （或 -M）选项来生成一个映射文件，显示它在内存中放入的内容和位置。对静态链接示例执行此操作可能会提供更多信息。
如果您不直接调用 ld，而是仅通过 gcc 命令行调用，则可以在 gcc 命令行中将 ld 特定选项传递给 ld，方法是在这些选项前面加上
-Wl,。If you want to find out what is being put into your executable, then ask your tools. Turn on the ld linker's --print-map (or -M) option to produce a map file showing what it has put in memory and where. Doing this for the static linked example is probably more informative.
If you're not invoking ld directly, but only via the gcc command line, you can pass ld specific options to ld from the gcc command line by preceding them with
-Wl,.在 Linux 上，链接器确实会合并多个模板实例。
确保您没有测量调试二进制文件（调试信息可能占用最终二进制文件大小的 75% 以上）。
减少最终二进制文件大小的一种技术是使用
-ffunction-sections和-fdata-sections进行编译，然后使用-Wl,--gc-sections< /代码>。如果您使用
[gold][1]的开发版本（新的 ELF-only 链接器，binutils 的一部分），并使用 < code>-Wl,--icf另一种有用的技术是减少共享库“导出”的符号集（默认情况下导出所有内容），可以通过 __attribute__((visibility(.. .)))，或使用链接描述文件。详细信息此处（请参阅“导出控制”）。
On Linux the linker certainly does merge multiple template instantiations.
Make sure you aren't measuring debug binaries (debug info could take up more than 75% of the final binary size).
One technique to reduce final binary size is to compile with
-ffunction-sectionsand-fdata-sections, then link with-Wl,--gc-sections.Even bigger reduction (we've seen 25%) may be possible if you use development version of
[gold][1](the new ELF-only linker, part of binutils), and link with-Wl,--icfAnother useful technique is reducing the set of symbols which are "exported" by your shared libraries (everything is exported by default), either via
__attribute__((visibility(...))), or by using linker script. Details here (see "Export control").一种非常粗略但非常快速的方法是查看目标文件的大小。并非目标文件中的所有代码都会编译到最终的二进制文件中，因此可能会出现一些误报，但它可以很好地了解热点的位置。找到最大的目标文件后，您可以使用 objdump 和 nm 等工具深入研究它们。
One method that is very crude but very quick is to look at the size of your object files. Not all the code in the object files will be compiled into the final binary, so there may be a few false positives, but it can give a good impression of where the hotspots will be. Once you've found the largest object files you can then delve into them with tools like
objdumpandnm.