代码库的哪些部分使二进制文件变大?

What parts of the codebase are making binaries large?

我已经为模拟器构建了一些代码,现在正尝试使用 TI 的免费工具链交叉编译为具有 64kb nvram 的目标。编译器声称我的代码超出 ROM 大约 34kb:

(...) msp430-elf/bin/ld: region `ROM' overflowed by 33716 bytes

另一行表示它无法将 .text 字段放入其分配的 space 中。我不敢相信我的添加总共有 34kb,更不用说导致二进制文件溢出这个数量了。

是否有任何工具或方法可以分解导致二进制文件如此之大的原因?

GNU binutils 有一些工具可以帮助您确定每个符号或每个目标文件的大小。

看看 size 例如:https://manpages.debian.org/jessie/binutils/size.1.en.html

nm也值得一试,因为它可以显示目标代码中每个符号的大小:https://manpages.debian.org/jessie/binutils/nm.1.en.html

仔细检查 sizenm 的输出会让您直观地了解什么占用了很多 space 什么没有。

知道 printfsprintf 和许多更复杂的库函数通常会占用相当多 kB 的额外 ROM。

与使用硬浮点相比,使用软浮点的浮点支持也会使代码膨胀,即使用软件仿真与硬件指令来处理浮点。

有时编译器会添加大量的膨胀:)

我曾经也遇到过微型 MSP430 控制器的内存问题。 如果可能出现负值或使用浮点数,TI 工具链会将大型库链接到您的二进制文件中。在我的例子中,它大约占总内存使用量的 10% - 20%。

TI 的免费 Code composer Studio 确实提供了非常强大的内存可视化(查看 -> 内存分配)

对我有很大帮助的是更改链接器设置中的初始化模型和其他优化选项。我目前没有使用 MSP430 控制器,所以我不能再告诉你细节了。

还有 AMAP,一个查看 .map 文件的小而简单的图形用户界面:http://www.sikorskiy.net/prj/amap/

如果有一个类似于 kdirstat 的工具,可以让您直观地比较符号大小,那就太好了。

虽然不是问题的直接答案,但我最终使用了 Voidware 的 CORDIC 实现来避免使用 <math.h> 中的大型函数:https://github.com/enthdegree/cordic_wrapped